[Issue 17708] Escape control characters in std.conv.to error messages

2022-12-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17708

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P3

--


[Issue 17708] Escape control characters in std.conv.to error messages

2019-12-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17708

berni44  changed:

   What|Removed |Added

 CC||bugzi...@d-ecke.de

--- Comment #2 from berni44  ---
Which controll characters need escaping? 0x00 - 0x1F only? Or are there more of
them I'm unaware of?

--


[Issue 17708] Escape control characters in std.conv.to error messages

2017-12-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17708

Jon Degenhardt  changed:

   What|Removed |Added

 CC||jrdemail2000-dl...@yahoo.co
   ||m

--- Comment #1 from Jon Degenhardt  ---
Encountered this case in my tools
(https://github.com/eBay/tsv-utils-dlang/issues/96). A user was processing a
DOS file (with `\r\n` line endings) on a Unix box, byLine left the extraneous
`\r` at the end of the line. My tool tried to convert to double, and output the
error text when this failed due to the `\r`. The formatting of the output is
quite confusing, as `\r` actually repositions to the start of the line,
effectively deleting the initial part of the output line. The result:

  ' when converting from type const(char)[] to type doubleUnexpected '

For my tools I'll add explicit detection of DOS line endings on Unix boxes,
it's just too common when getting data files from a variety of sources.
However, it'd be helpful to update error message generation to handle `\r` and
other non-printing characters.

--


[Issue 17708] Escape control characters in std.conv.to error messages

2017-07-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17708

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12260

--