Path: 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: 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 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