Re: [cc65] A bug?

On Wed, Jul 23, 2008 at 03:29:19PM +0200, silverdr@inet.com.pl 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
different word widths, different int sizes, different line endings, different
representations of the NULL pointer and so on. Some were more common and
others less. This is the reason why C doesn't standardize such things. It does
neither require 8 bit bytes nor a NULL pointer that consists of zero bits nor
lines that end in a special character. 

Anyway, programmers were sloopy and created programs that expected bytes with
8 bits, NULL pointers that consist of zero bits, ints with at least 32 bits
and lines that are terminated by special characters. Since software is much
more expensive than hardware, the hardware devlopers followed this path and
dropped CPUs with unusal register widths. Dito for operating systems. This led
us to the more or less uniform landscape we have today.

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
times the variety of systems was greater than today. They're fully covered by
the C standard, because the basic C standard was developed in these times. But
they're not comparable to todays systems. So even if your program runs on a
few of todays machines it is still not portable. This is not a bad thing per
se. Many things are rather difficult to do or become slow if you do it really
portable. I've written a lot of software for a system with 32 bit bytes, and
can tell you that there is almost no C code to reuse, at least not the low
level stuff.

> 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.
"Text mode" means that line endings are translated to or from whatever the
system uses to terminate lines. If you read in a line from a file in text
mode, the C standard says, that the line ending - regardless how it is
implemented on the platform - has to be translated into "\n". Using this
trick, C programs that worked on the Unix platform where Unix stems from
worked without problems on other systems. 

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.

Regards


        Uz


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