Article View: comp.sys.amiga.tech
Article #77Re: strins()
From: Tom Limoncelli
Date: Sat, 17 Jun 1989 03:36
Date: Sat, 17 Jun 1989 03:36
63 lines
3191 bytes
3191 bytes
My understanding of the ANSI standard is as follows:
The original draft insisted that if you create a function that has
the same name as something in the standard library, the behavior
was implementation defined with the warning that you might have
problems if you write a function called printf() that (for example)
formats disks. Pray that none of the other library routines use
your printf instead of their intended one.
The second draft states that "the library names are (in principle)
[now] reserved names. If you write your own version of fopen, say,
your program MIGHT work in some environment that you know well, but
it would have slim chances of being generally portable." {footnote:
The C Journal, Summer 1985, "Draft ANSI C Scorecard -- Second
Round" by Thomas Plum, pg 29-34}
Of course, this is not completely helpful nor is it a generally
good way of dealing with this problem. So, in a later draft [no
footnote here, this is "as I understand it"] the X3J11 committee
decided to adopt a better method. Now if you want to write your
own "fopen" routine, that is, if you want to write a routine named
"fopen", not replace "fopen"'s functionality with a function of
your own:
#undef fopen
then you have full access to that reserved word. If you think
about it, it makes sence. Basically, fopen has a definition. If
you want to change it, undefine it and redefine it yourself. Just
like if you want to (eeek!) change the value of EOF.
#undef EOF
#define EOF (-69)
This is also very easy to implement. If a vender wants to
implement a function as inline code, they use a very long #define.
If the user doesn't want it to be inlined, they simply #undef it
and now the linker will try to find that routine first in the
current module (.o file) then in one of the libraries. ANSI also
dictates that the linkers must perform in this way.
If the vender doesn't want the function to be inlined, they call it
(for example) __stlib_fopen and do a #define fopen __stlib_fopen.
All identifiers beginning with "__" are the domain of the vender,
so there will be no namespace conflict. I don't recall how they deal
with the #undef'ed identifier, I wouldn't expect them to put
__stlib_fopen and fopen in the library (duplicate code). Maybe someone
can follow up on this.
Simple? I think it's very workable.
I hope this explanation is helpful, I know it was a bit long winded
but I think it covered all the bases.
Please correct me if I'm wrong. As I said, this is how I
understand it.
-Tom
--
Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net
Drew University -- Box 1060, Madison, NJ -- 201-408-5389
Standard Disclaimer: I am not the mouth-piece of Drew University
Technical Details
Message-ID:
<Jun.16.23.36.52.1989.29150@pilot.njin.net>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!limonceReferences:
<8906150029.AA22430@jade.berkeley.edu> <3930@sugar.hackercorp.com> <17740@louie.udel.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.sys.amiga.tech Subject: Re: strins() Message-ID: <Jun.16.23.36.52.1989.29150@pilot.njin.net> Date: 17 Jun 89 03:36:52 GMT References: <8906150029.AA22430@jade.berkeley.edu> <3930@sugar.hackercorp.com> <17740@louie.udel.EDU> Organization: Drew University/NJIN Lines: 63