Re: [cc65] A bug?

On 2008-07-23, at 21:35, Ullrich von Bassewitz wrote:

>> Don't get me wrong but the code in question didn't require any kind
>> of "special treatment" on any of the compilers/platforms I used in
>> the past. And the plural here means several times more than two.
>
> Once, when C was created, there were a lot of different platforms.  
> They had
[...]
> Just because your program runs on a few of todays systems, that does  
> not mean
> it is portable. The 6502 machines cc65 is made for are lot older and  
> at these
[...]

Thank you Ullrich. I truly appreciate you taking time to explain  
things in such clarity. It is still that I didn't concur. That was the  
part of "don't get me wrong". It is only that I was very much  
surprised to learn that \r is not portable (one learns throughout the  
whole life, right?) because I was taking the whole \whatever set as  
granted to be part of the "standard" C and therefore portable.  
Additionally there was no exception to prove me wrong, and not only on  
the modern machines. The code in question comes from the late eighties  
or early nineties and processes some - quite big - text files. It ran  
already on the very old DOS boxes, some ancient HP-UX and others of  
the era. I wanted to compile it and run some tests using the IDE64  
(the files to process wouldn't fit on a 1541 floppy, not to mention  
the time required to read/write it).

>
>> As I
>> wrote some time ago - it was the first time I encountered this kind
>> of problem since shortly after the K&R publication. \r worked as
>> expected even on non-unix-relative platforms like IBM C/2 compiler
>> generating binaries to run under DOS (and the OS/2) . I take that the
>> compiler there had to make "special treatment" for \n as two code
>> sequence was needed there.
>
> The different line endings are the reason why C has a "text mode"  
> for files.
> [...]
>

I lived under the assumption that "text mode" was not only because of  
line endings but generally because of (various) control sequences  
being often very much different across the multitude of possible  
output devices. If that is not true then I learned one more thing today.

> There is no such definition for \r in the standard. This is because  
> Unix used
> terminals at that time which and different models had different  
> characters
> strings assigned to the "carriage return" capability. For this  
> reason, the
> termcap library has its own code named "cr" to define the string for a
> specific terminal. So using \r might not work on several old Unix  
> platforms
> too, depending on the terminal that is in use.

Yes - that is what I eventually understood: termcap without proper  
sequence for \r = no \r behaviour. It just happened that the 64 was  
the first I ever encountered, which didn't have this capability. 128  
supposedly has it but I didn't test yet if \r works there.

Thank you once more for your time spent on this.

Regards,

P.

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.