Machine specific predefined names

[Karl Heuer]

The story so far: Terry observes that redefining a library function usually
works, and asserts that it works on all known machines.  Larry points out that
it doesn't produce the correct behavior for putchar(), as in the original
example.  Now in article <378 at wsccs.UUCP> terry at wsccs.UUCP (terry) writes:

>Please look at your synopsis and note that it refers to 'redefinition
>of library functions'... then note that putchar() is not a library function,
>[but a macro], and that it is possible to redefine it by '#undef'ing it first.

But (on most UNIX systems) that does not "redefine" the routine in the sense
that other units, like printf, will suddenly start using yours instead of the
real one.  Moreover, not all systems implement putchar() as a macro.  If you
try to redefine *any* standard routine -- whether macro or function -- the
result should be, and is, undefined.  Why should the user be forced to learn
the implementation details?

>>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'?

It allows better optimization.  E.g., inlining of the <string.h> functions.

>>>For example, get 5 UNIX machines, [and try printf(NULL)]
>>your program is WRONG.
>Of course it's wrong!  That's the whole point!

I don't get it.  What do you think *should* happen if you pass a NULL pointer
(appropriately cast) to printf()?

>[I am] against a language standard that ... allows or requires someone to
>write code that won't run on another machine.

No useful language can disallow this; see HAKMEM item #154.  If the dpANS
*requires* it, I'm sure the X3J11 committee would like to hear it.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint