Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!gargoyle!ihnp4!occrsh!uokmax!rmtodd
From: rmtodd@uokmax.UUCP (Richard Michael Todd)
Newsgroups: comp.lang.c
Subject: Re: Passing (char *) NULL to printf to match %s
Message-ID: <649@uokmax.UUCP>
Date: Wed, 26-Aug-87 12:22:51 EDT
Article-I.D.: uokmax.649
Posted: Wed Aug 26 12:22:51 1987
Date-Received: Fri, 28-Aug-87 07:31:11 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <1219@cognos.UUCP> <25173@sun.uucp> <298@apex.UUCP> <2163@xanth.UUCP>
Reply-To: rmtodd@uokmax.UUCP (Richard Michael Todd)
Organization: University of Oklahoma, Norman
Lines: 83
Keywords: MSC,NULL segments
Summary: Doesn't seem to me to be that much of a problem


In article <2163@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>[I just _know_ this is gonna get me flamed.  Line eater, eat this posting!]
>Is it just me, or has anyone else noticed how C is being warped, made
>ugly and complex, because ONE microprocessor manufacturer couldn't see
>fit to provide a flat, linear address space?  How about if we just
>write off the 8086 and 80286, and the usual mode of the 80386, and
>design C as if pointers were NOT structures, there was only ONE
>address zero, and so on?  If someone _has_ to use those bizzare devices,
>let him invent a compiler that reads "virtual machine C" (i.e., flat
>address space) and kludges it for the weird case, but let the standard
>C language treat the machine as if designed by a rational being.
I have a PC with one of those processors in it, and I program in C, and
I fail to see just what is being 'perverted' in C on the 8088.  As I
understand it, it has never been guaranteed that pointers will fit into an
int; such code is non-portable to other machines besides PCs with their wacky
memory models.  
  I vaguely recall that the original discussion was on something like
problems with Microsoft C because some valid data object was placed at address
0.  Well, Microsoft C may be broke, but Aztec C's linker makes sure that
none of the user's data has address 0 in the data segment.  (From what I've
heard, Microsoft C is broke in lots of other ways, too :-(). 
  As for the nonsense with declaring 'near' and 'far' pointers for the
mixed memory models, I don't like it much, either.  It's a pure efficiency
hack;  a program can be written entirely with the large data model, but it'll
be slower than the 'optimized' version with mixed-memory model.  Frankly, I've
*never* done anything where I felt I needed it. 
  Is there something else here I'm missing that causes problems with C
on the 8088?  Frankly, while I don't *like* the 8088 segmentation setup, and
I doubt anyone else much does either, it doesn't seem to cause that much
trouble. 
  Now that that's over with, I'll put forth my flame against a certain
characteristic of MSDOS that *I* feel is perverting C, and which I have found
to be much more of a pain in the rear end than any memory-model nonsense.
>>>>>>>>>FLAME ON<<<<<<<<<
I refer to the wonderful "feature" of MSDOS that has all text files in a
format where the lines are terminated by CR and LF instead of just LF alone.
This causes great problems with the C library, which was designed around the
implicit assumption that lines are terminated with one character only, called
'\n'.  This requires all sorts of disgusting kluges.  The two main approaches
seem to be the Lattice/Microsoft approach of requiring the file to be opened
in a special "binary" mode if the automatic CRLF->newline mapping is to be
disabled, and the Aztec approach of having the I/O function used determine
whether mapping is done.  Under the Aztec approach, functions such as
read(),write(),fread(),and fwrite() do binary (untranslated) I/O, whereas
fprintf(),fscanf(),fputs(), fgets() do ASCII I/O.  There are functions
getc() and putc() for single byte binary I/O, and agetc() and aputc()
for single character ASCII I/O.  Getchar() and putchar() are #defined in
terms of agetc() and aputc().  I prefer the Aztec approach, because it seems
to do what is 'right' most of the time; most of the time you mess with binary
files thru read() and write(), and with text files thru gets(),puts(), etc.
If you need to do text I/O on single characters from all files in your program,
you can just put
	#ifdef AZTEC
	#define getc agetc
	#define putc aputc
	#endif
in a header file somewhere.  I prefer the Aztec approach, but alas the other
approach seems to be the one blessed by the ANSI standards committee. 
  But, in case you've missed the point in all this digression about I/O
functions, NONE OF THIS GARBAGE WOULD BE NECESSARY if the standard text 
format was designed more sensibly.  In fact, except for the built-in device
drivers for the console and printer in MSDOS and the built-in TYPE command,
files with LF-only-terminated lines work just fine on my system. This is
due to a neat feature of the Aztec C I/O routines:  When reading in text data,
they do CRLF->LF mapping in the most obvious way--simply throw out any CRs
in the input.  This means that if the file is already in Unix-style LF-only
format, the I/O routines handle it with no problem whatsoever.  My copies
of MicroEMACS and Less, compiled with Aztec C, handle Unix-style files with
no problem at all, as will the C compiler itself (evidently Aztec uses their
own compiler). It's only the MSDOS commands and drivers that require the
CRLF.
  So, in analogy with Kent's question, I ask:  Is the C library going to
continually be perverted to accommodate braindead operating systems of
the past that can't handle text files correctly?
>>>>>>>Flame off<<<<<<<<
  (Yes, I suspect there will continue to be altered I/O libraries that
accommodate the weirder operating systems out there.  But I don't have
to like it much.  Oh well.  Anyone for XENIX? :-)
--------------------------------------------------------------------------
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!occrsh!uokmax!rmtodd