Lattice/UNIX incompatibility

[guido at boring.UUCP]

In article <345 at rna.UUCP> kc at rna.UUCP (Kaare Christian) gives a list
of Lattice incompatibilities with unix (not with K&R!), which is basically
correct.  Some minor corrections:

>	10. Pre processor macros with arguments are limited to a
>single line.  This is what the manual says. I don't know if you
>can escape the newline as is routinely done in Unix versions of C.

This can be done in the *definition* alright (though the whole of the
definition must be fairly short -- 150 chars in the version I'm used to),
but not in the *call*.

>	11. The open and fopen system calls must be told if you want to
>treat the file as a binary file.  The default is to assume an ASCII
>file, with disastrous consequences for many programs.
>I think the default for read (and probably for fread) should be
>to give the programmer the data, raw and uninterpreted.

The problem with this is that a newline on PC-DOS is CR LF, while most
UNIX programs assume to receive only a LF ('\n') at the end of a line.
This is a more important consequence of the binary/ascii mode given at
open time than the ^Z treatment.  Unfortunately the interface Lattice
choose was to set the mode at open time, and since their standard I/O
library uses their own read/write functions, one cannot specify that
the translation has to be done for getc calls but not for [f]read.
I would like it most if 'open' would have binary as default, and 'fopen'
ascii.

Regarding the ^Z treatment: this still makes some sense because the
PC-DOS COPY command, and probably others, places a ^Z after
each file copied in ascii mode (which is the default mode); naive C
programs would probably burp if they saw the ^Z.  We are, alas,
living with an OS whose main utilties don't know the power of the OS!
(RENAME can't move to another directory, etc., etc.)

	Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
	guido at mcvax.UUCP