Re: [cc65] A bug?

On 2008-03-05, at 23:56, silverdr@inet.com.pl wrote:

>> The C spec requires that "\n", regardless of its in-memory
>> representation,  maps on I/O to whatever the normal end-of-line
>> convention is on the platform.  On the Commodore, at least, that's
>> clearly a bare carriage return.  On the Atari, it should proably come
>> out as chr$(155) (IIRC).
>>
>> The C spec further requires that "\n" and "\r" have different
>> representations in memory, such that '\n' == '\r' is never true.
>>
>> However, it does not require '\r' to have any particular effect when
>> output.  That's up to the output device.
>
> If that is defined exactly as you write in the current C standard,  
> then the question is of course invalid but it still surprises me. I  
> haven't read any specs on C. I learned it many years ago from K&R.  
> It was some time before C even get standardised but I must have  
> learnt it from K&R how \r behaves and I know that I relied on this  
> behaviour many times in the past and this was the first time I found  
> it not working as expected.

Returning to this old thread... I found myself again in need of  
"proper" \r behaviour and started to look if I write my own function/ 
macro/whatever or rather patch the lib, and.. I found the code for  
handling the \r sequence "properly" in many places. For example in  
cputc.s. I checked and indeed the cputc() does handle \n and \r  
differently and "properly" - meaning - \n generates newline while \r  
only returns the cursor to column zero - the way I would expect it to.  
Wondering if/why can't it be cone across the codebase? Code for  
returning the cursor to column zero is a simple PLOT call on CBM  
machines. I believe it not to be too complicated for someone with good  
knowledge of the lib sources' structure and IMHO this would add a good  
point to the overall source-level compatibility of CC65 programs.

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