Re: [cc65] A bug? (was: Questions for CBM guys)

On 2008-03-05, at 13:39, Greg King wrote:

>>
>> So, I checked -- seems that it actually _doesn't_ achieve "\r"  
>> properly!
>> I wrote a simple:
[...]
>>
>> Is this a bug or a feature?  I know it is not very  
>> straightforward; but
>> AFAIR, it still can be achieved with a combination of SCREEN and PLOT
>> calls without too much hassle, can't it?
>
> It is a feature.  When cc65 and ca65 translate ASCII into PETSCII,  
> they swap
> the values of '\r' and '\n'.

Hm, but that's something which I find strange. To me '\n' (or '\r')  
doesn't have a value. It has a function and it should be translated  
into whatever is required to achieve this function on a specific  
platform. Of course we got used to think that '\n' == LF == 0x0a but  
it in fact is not so, is it? Otherwise we wouldn't need this kind of  
abstraction and just put the $0a value into the format string.

> The CONIO functions do obey both '\r' and '\n' -- in the MS-DOS way.

Again - '\r' != 0x0d and '\n' != 0x0a ! IMHO '\r' should perform the  
same function in STDIO on every platform.

> And, I
> think that we can mix CONIO and STDIO functions on the CBM  
> platforms.  We
> can use the positioning functions, such as gotoxy().

Well, certainly there is a number of ways to achieve the desired  
result but I was not really asking "how to achieve '\r' function when  
it doesn't work in STDIO?" but rather "why is that so that '\r'  
doesn't work in STDIO?"


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