Escape codes are not 100% portable
na via Digitalmars-d
digitalmars-d at puremagic.com
Fri Apr 3 02:39:58 PDT 2015
You can convert to host encoding, gets more interesting if you
have worked with data from 390's.
Anyway here is the Newline reference from Unicode.
http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf#G10213
na
On Thursday, 2 April 2015 at 13:57:32 UTC, Steven Schveighoffer
wrote:
> On 4/2/15 9:05 AM, Jens Bauer wrote:
>> On Thursday, 2 April 2015 at 12:24:22 UTC, Kagamin wrote:
>>> On Thursday, 2 April 2015 at 11:42:50 UTC, Jens Bauer wrote:
>>>> On the other hand, if a file was copied to a platform, where
>>>> \r = 13
>>>> and \n = 10, and the file contains lines ending in 0x0d,
>>>> then this
>>>> compiler would not be able to build the file.
>>>
>>> Where it will fail? It can see extra lines, but those are
>>> whitespace,
>>> the source should compile just fine.
>>
>> You're right here; because the D compiler does not require
>> reading
>> line-by-line.
>> The line numbers reported will be incorrect, but that's
>> probably the
>> worst that can happen.
>>
>> However, in a case like PPM (Portable Pixmap Format), the
>> problem is
>> that when the first \n character is met, the format switches
>> to binary;
>> but that will not occur until we've already read a bunch of
>> bytes from
>> the binary stream, resulting in the picture being out of sync.
>
> After reading all this thread, I can safely say, I'm OK with D
> not targeting these platforms.
>
> In addition, "Not portable" doesn't mean "buildable without any
> changes".
>
> Is it not considered a porting activity to just change those
> constants for that version of DMD?
>
> And finally, if the files are written for that platform, won't
> they have this wonky coding anyway? And if they are files from
> another platform which treats \n and \r traditionally, won't
> editors on that platform do the same thing with line numbers? I
> really see no problem with the way the code is.
>
> -Steve
More information about the Digitalmars-d
mailing list