Machine specific predefined names

[terry]

In article <242 at sdrc.UUCP>, scjones at sdrc.UUCP (Larry Jones) writes:
> In article <302 at wsccs.UUCP>, I wrote:
> [discussion on redefining library functions culminating in the observation
> that it usually works]
> > 
> > 	I know of over 200 machines that work this way, > 120 from personal
> > experience.  Contrary to what Larry has said, Ray, I know of no machine that
> > does _NOT_ work this way.  
> 
> Well, how fortunate you are.  Try redefining putchar() like in Ray's original
> example some time.

	Please look at your synopsis and note that it refers to 'redefinition
of library functions'... then note that putchar() is not a library function,
that it is defined in stdio.h [#define putchar(x) putc(x,stdout)], and that it
is possible to redefine it by '#undef'ing it first.

> When the preprocessor does macro substitution on your function definition
> you'll get some really interesting error messages.

If I were so naieve as to think the _linker_ handled preprocessor statements.

> As compilers get smarter you're going to have more and more problems with
> this kind of stuff and some of it can be really hairy to track down.

Enlighten me.  How is absolutely reserving things in addition to the current
reserved word list 'smarter'?

> As an example, we have our own version of the memory allocation functions
> (malloc, realloc, etc.) that we use for debugging - when we got a new
> release of the library, we discovered that if you opened a particular type
> of file and did a particular sequence of operations, the program would bomb.
> Turned out that an obscure piece of the I/O library was using the block
> header on the file buffer (which was know to have been malloc'ed) to
> determine its length.  The header format had been changed and our routines
> were still using the old format.

Block header?  You mean 'struct mallinfo'?  That is why you are supposed to
[#include <malloc.h>].  Certainly you can't mean that you had a problem due
to a change in [struct file] in <sys/file.h>?  Were you malloc'ing memory
from a file?

I wrote:
> I think you would be pretty safe in assuming that
> _all_ machines work this way.  If they don't, then piss on them.  Their
> manufacturers will soon find out that they have to change the behavior of
> their linkers, or not have products ported to them.  

Larry replied:
> Sure, just take your ball and go home.

No, take my _w_a_l_l_e_t and go elsewhere.

> Just be sure not to complain about vendors who tell you to go read the
> standard and refuse to change.

Oh.  You have anyone specific in mind?  IBM, DEC?

> Also, don't complain about the compile, link, and execution speed on those
> machines that work like you want.

"Anything that works is better than anything that doesn't"

Besides, the K&R compiler on the CRAY runs _much_ faster than the ANSI
compiler it doesn't have :-).

> > I defend this position
> > by pointing out that while C is standard, libraries are not, and to get
> > portable code depending on a library function, you MUST rewrite the library
> > function for it to operate consitantly.  
> 
> Say what?  If X3J11 hadn't bothered to standardize the libraries they would
> have been done a couple years ago.  The libraries ARE standard.

Ok.  What is the "standard" ioctl() call to make a BSD system, a SysV system,
an MS-DOS system, and a VMS system put the terminal into "raw" mode so I can
port my MicroEMACS?  WHAT!?!  I have to call it with different parameters for
BSD and SysV?!?  I have to make SYS$QIO(p1, p2... p12); calls on VMS?  I have
to call ASSEMBLY on MS-DOS?  I thought you told me these libraries for C were
_s_t_a_n_d_a_r_d!

What do you mean that "curses doesn't work right with AM terminals"?

> 
> > For example, get 5 UNIX machines,
> > of any flavor, and compile and run the following fragment:
> > 
> > 	#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).
> 
> You get similar behaviour from things like:
>     *(char *)0 = 5;
> The cause is the same - your program is WRONG.

Of course it's wrong!  That's the whole point!  What if I have a bug in my
LISP interpreter that passes a null to printf if it recurses *exactly* 57
times through a routine?

The whole point is, you can't get perfectly error-free code when you depend on
library routines written by some kid at Berkley who is getting paid workstudy
wages by a cognitive psychologist so he doesn't have to fry hamburgers to pay
for his dorm room.

The 'printf()' function was only an _example_, not of goood code, but of code
that acts OK on 14 out of 15 machines and core dumps on the 15th.

> Read the draft standard and follow it and you won't have these problems.

Ah yes.  I see that you, like me, write code that never needs to be run through
a debug routines ;-).  The problem with the "draft standard" is that it is not
necessarily backward compatable.  I am not against a more rigorous compiler,
simply against a language standard that 1) is _still_ amorphorus, and 2) allows
or requires someone to write code that won't run on another machine.  Port the
VMS version of moria (in pascal) to Turbo Pascal IV... "both comply with the
ANSI standard, it'll work, no problem". RIGHT.

I said:
> 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.

OK, maybe it won't go away.  But it should.

> AT&T has stated they will provide an ANSI compiler and the POSIX standard
> requires one.

The 'POSIX standard'?  When either an 'ANSI standard C' or a 'POSIX standard'
exist in immutable form, I might be inclined to agree with you... By the way,
when did AT&T say that?

> I doubt that many vendors will supply one compiler and use a different one
> to compile the OS.

Agreed... which is why I think an ANSI standard will have a long ways to go
to gain acceptance.  Of course, we may be wrong... I know of at least one UNIX
that is currently being written in Modula2.

> If K&R is all you need, complete with its ambiguities, conflicts, and errors,
> then just go bury your head in the sand and forget about portability.  No
> one's going to want what you're doing anyway.

It's _NOT_ all I need!  Far from it!  But it runs on more machines than a
currently non-accepted "standard" which still has to be accepted.  As long as
there are more machines running K&R, I will program K&R... unless I'm paid to
program something else :-).

Your arguments remind me of the programmer who would only program in this
obscure language called IBM/JCL, convinced that his programs would someday
run on all machines, as the other vendors "came to their senses".


| 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...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |