Machine specific predefined names

[terry]

In article <302 at wsccs.UUCP> I write:
>I don't believe everybody will rewrite their UNIX in ANSI C, anyway, so lets
>all hold our breath, and it will go away, leaving only K&R and some idiots
>blinking their eyes at the sudden light.

In article <10646 at mimsy.UUCP>, Chris Torek replies:
> This is, I think, naive.  A number of vendors are fanatically tracking
> the dpANS even now.  4BSD may be slow to follow (as in `you will have
> to wait for 4.4BSD to have even a faint hope of seeing an
> ANS-conforming compiler' [well, you can try GNU CC in the interim]),

A great deal of developers in the real world like their code to compile and
don't like to change it (thus possibly introducing errors) once it does.
That means that with the current volume of code out there, there is a *LOT*
of inertia against the ANSI standard.  I think you will find "GNU C" conforms
to the proposed ANSI standard, since there isn't a real one yet.  I may not
even do that, after the recent changes.

> and I believe some vendors will provide two flavours of C (to work
> around the botches[1] in the standard until everyone can change their
> code), but the standard looks very real.
> -----
> [1] E.g., widening rules for unsigned (yes, I am going to harp on that
> one forever).

This may be the case, but I will hold off on prototyping until all the machines
I want to run on or that I may (or may not) want to run on in the future
support prototyping.

I think a better target for standardization would be system libraries and
executable file formats.  I think it would be nifty to be able "port" a program
by simply having the converter "know" what a system call looks like on a
certain machine and translating only the specific assembly instructions.  I
have seen such a program move an object file from an NCR tower to a Xenix
system.  Admittedly, with current vendor specific code files, this would only
work on simpler programs.  Wouldn't it be nice if there were only one UNIX
kernal (eventually), given that optimization is not sacraficed in the
conversion (Intel <=> Motorolla would probably be a sacrafice).  I think that
this goal is a long way off; ioctl() doesn't even work uniformly from one UNIX
(BSD) implimentation to another.  It would be nice if all I had to do to port
from a BSD to a SysV machine with a 680x0 was tar a tape.

> As an aside, terry asks us to run the following to see why, he believes,
> people need to write their own `printf' functions, spurning those in
> the supplied libraries:
> 
> >	#include <stdio.h>
> >	main()
> >	{
> >		printf( NULL);
> >	}
> >
> >Some systems will core dump, some systems will do nothing, and others will
> >print the string '(NULL)' (my quotes).
> 
> True.  Some might even catch your bugs at compile time!

And some won't.  My point in a nutshell.

> If you do that, all bets are off, just as if you do *this*:

[core dump fodder deleted]

> Note that the line
> 
> 	printf(NULL);
> 
> contains two bugs.  First, it should be
> 
> 	printf((char *)NULL);

I believe I #defined NULL that way...

> 
> and second, printf is not supposed to be passed (char *)NULL.

And how do you debug it in a recoverable fashion so that you know it is going
to happen?  Besides, you don't release a product with a function which is not
written the same from system to system, unless you have source and agree with
each implimentation, and they agree with each other (they don't).  printf()
was simply a handy example.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 }                          |
| @ Century Software          : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'The ink is black; the page is white; Only K & R wrote C right...'          |