Machine specific predefined names

Doug Gwyn gwyn at brl-smoke.ARPA
Sat Mar 19 11:35:39 AEST 1988


In article <302 at wsccs.UUCP> terry at wsccs.UUCP (terry) writes:
>	In specifying either behavior, the draft would have to dictate the
>actions of the linker.

"This happens not to be the case."  The (proposed) standard specifies a
"treaty point" between the application and the implementation.  Violation
of the treaty has "random" consequences including occasionally being able
to get away with it.  But the prudent programmer will follow the rules.

>This means that in 99% of the cases, your putchar would be used.

Except that putchar is a macro, so yours wouldn't be used after all.
To make this a reasonable dicsussion, use fputc() or some other
function that MIGHT be used by the C library implementation.

>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.

Ha, if C were "standard", we wouldn't have had to spend years figuring
out a standard for it.  X3J11 early on realized that a significant
amount of the C library also needed to be standardized.  It would be
stupid to perpetuate the idea that every application needs to carry
around its own implementation of the C library.

>For example, get 5 UNIX machines,
>of any flavor, and compile and run the following fragment:
>		printf( NULL);

So systems do different random things when you violate the interface
specs.  So what?

>I don't believe everybody will rewrite their UNIX in ANSI C, anyway...

No, it's being redone in C++.  That's totally irrelevant.



More information about the Comp.lang.c mailing list