Machine specific predefined names

David Collier-Brown daveb at geac.UUCP
Tue Feb 23 23:25:32 AEST 1988


In article <1988Feb21.015424.20436 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
> while something like "open" clearly ought to be available under that
> name, it would also be nice to have it available under some implementor-
> reserved name like "__open" so that, say, "fopen" could call it without
> requiring the user to avoid using "open" as the name of one of his own
> functions.

In article <17033 at watmath.waterloo.edu> rbutterworth at watmath.waterloo.edu (Ray Butterworth) writes:
>     #include <stdlib.h>
>     #include <stdio.h>
>     int open() { perror("open failed"); abort(); }
>     main() { if (!fopen("xx", "r")) open(); }
> 
> Assuming I didn't make any typos, that is a correct ANSI program.
> But if the ANSI fopen() uses my version of open(), it won't work
> correctly.
[discussion elided]

  This is a serious, long-standing Unix-specific problem, inherited
without change by many unix-like and unix-derived systems....

> I am used to working on two different systems.  One of them uses
> special entry points for all internal library calls, the other
> uses no such special names....

  Sounds like the (Waterloo SDG) C compiler for God's Chosen Operating
System.

> 
> From my point of view, the internal-name-for-everything approach
> is clearly better, since a user that inadvertently redefines an
> ANSI function (especially one that won't be invented for a couple
> of years yet) won't get an unpleasant surprise. 
>
   That the developers of Unix didn't deal with this (known) problem
for their limited purposes is unfortunate.
   That subsequent developers, including Berkey and TellBellaphone
Sales, did not deal with it reflects strongly to their discredit.

 
> I didn't see anything in the standard to indicate that either of
> these behaviors is right or wrong.

  That the ANSI committee have chosen to ignore the problem is
understandable, under the circumstances.  It is also an admission of
incompetence and/or malfeasance, but that's a different discussion.

 --dave (history? we don't read history, we repeat it!) c-b
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.



More information about the Comp.lang.c mailing list