henry@utzoo.uucp (Henry Spencer) (02/22/90)
In article <MCDANIEL.90Feb20172440@orenda.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >What names are reserved in ANSI C? ... Unfortunately, there are a whole pile of them, and they don't follow any particularly regular pattern. Everything in the ANSI C library is reserved, modulo some small escape clauses for things like macros if you don't include the relevant header file(s). And there are a bunch of reservations for future expansion, some of which are macros and hence applicable only if relevant header files are included, some of which are external names and hence are reserved regardless. For example, not only are all the function names in <math.h> reserved, so are those names suffixed by "f" or "l", for future provision of float and long-double variants. Over and above the existing C-library names, and the <math.h> extension reservation, the list is: _[_A-Z].* everywhere for all purposes _[a-zA-Z0-9_].* everywhere as file-scope identifiers and tags E[0-9A-Z].* in <errno.h> (is|to)[a-z].* as external names, and in <ctype.h> LC_[A-Z].* in <locale.h> SIG_?[A-Z].* in <signal.h> str[a-z].* as external names, and in <stdlib.h> or <string.h> mem[a-z].* as external names, and in <string.h> wcs[a-z].* as external names, and in <string.h> >... How about in the current UNIX >standardization effort? POSIX basically goes by the ANSI rules unless you define _POSIX_SOURCE before including headers, in which case more standard names appear. Also there are some POSIX-specific headers. In particular, <sys/types.h> can define any .*_t name. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
phg@cs.brown.edu (Peter H. Golde) (02/22/90)
In article <MCDANIEL.90Feb20172440@orenda.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >I think that identifiers that match these regular expressions are >reserved to an implementation: > __.* > _[a-zA-Z].* with external linkage? > is.* only if <ctype.h> is included? > E[A-Z]* for error codes? >Yes? No? I believe math functions ending in "l" are reserved for long double math functions, i.e. "sinl", "log10l", etc. --Peter Golde
drd@siia.mv.com (David Dick) (02/24/90)
mcdaniel@amara.uucp (Tim McDaniel) writes: >What names are reserved in ANSI C? (Surprisingly, neither K&R2 nor >Koenig seem to have this information.) How about in the current UNIX >standardization effort? How about the couple of hundred names in the standard library? Remember that you can no longer "roll your own" version of any of these routines. David Dick Software Innovations, Inc. [the Software Moving Company(sm)]
karl@haddock.ima.isc.com (Karl Heuer) (02/26/90)
In article <1990Feb23.184656.3110@siia.mv.com> drd@siia.mv.com (David Dick) writes: >[The names in the standard library are also reserved] >Remember that you can no longer "roll your own" version of any >of these routines. You never could. The rules haven't changed in that respect; only the degree of formalism in stating them. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
mcdaniel@amara.uucp (Tim McDaniel) (02/27/90)
drd@siia.mv.com (David Dick) writes:
[The names in the standard library are also reserved]
Remember that you can no longer "roll your own" version of any
of these routines.
Are standard library names utterly and completely reserved, or can I
fake it with #define, as in
#define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__)
--
Tim McDaniel
Applied Dynamics International, Ann Arbor, MI
Internet: mcdaniel%amara.uucp@mailgw.cc.umich.edu
UUCP: {uunet,sharkey}!amara!mcdanielgwyn@smoke.BRL.MIL (Doug Gwyn) (02/28/90)
In article <MCDANIEL.90Feb27103334@amara.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >Are standard library names utterly and completely reserved, or can I >fake it with #define, as in > #define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__) You may #define your own malloc macro only if you don't #include <stdlib.h>. However, C library functions that need to allocate storage may invoke the real malloc() library function to do so; consequently your my_malloc() implementation had better not interfere with the standard malloc(). The usual way to guarantee this would be for my_malloc() to obtain its own memory pool via malloc() and reallocate portions of it according to its own notions. It would be better to use some name other than malloc for this macro.
seanf@sco.COM (Sean Fagan) (02/28/90)
In article <16021@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <1990Feb23.184656.3110@siia.mv.com> drd@siia.mv.com (David Dick) writes: >>Remember that you can no longer "roll your own" version of any >>of these routines. >You never could. Huh? Since when? You could always write your own strcpy (although things might not have worked), until now. Since strcpy may not even *be* in the library, just in the compiler, that makes it kinda hard to write your own. -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
martin@mwtech.UUCP (Martin Weitzel) (02/28/90)
In article <MCDANIEL.90Feb27103334@amara.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >drd@siia.mv.com (David Dick) writes: > [The names in the standard library are also reserved] > Remember that you can no longer "roll your own" version of any > of these routines. > >Are standard library names utterly and completely reserved, or can I >fake it with #define, as in > #define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__) To be save, you should write a line #undef malloc before your redefinition (because every library-function might be defined as well as macro, if you include the appropiate standard header - stdlib.h in this case). To be save *and* portable you might even have to write: #ifdef malloc #undef malloc #endif #define <your own malloc> The latter is *not* required in ANSI-C, because #undefs are legal if the given name is not defined as macro. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
mcdaniel@amara.uucp (Tim McDaniel) (03/01/90)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
You may #define your own malloc macro only if you don't #include <stdlib.h>.
...
It would be better to use some name other than malloc for this macro.
Suppose I just want to put a wrapper around a system function. For
instance, free given a NULL argument could just do nothing (if my
system's supplied free would abort in such a circumstance). Or
suppose I'd like to record a stack trace.
In such a case, I would like to just do
extern void * my_malloc(size_t);
#undef malloc
#define malloc(x) my_malloc(x)
where my_malloc does wrapperish stuff and then calls the real malloc
to do the real work. I'd set up "my_stdlib.h" with such declarations.
So, if I ever #include <stdlib.h>, even if I #undef malloc as a
precaution, I can't #define a new malloc? That's a bummer. (By using
a my_stdlib.h, there's a workaround, but it's still an annoyance.)
I assume the reasoning is that the compiler might have, say, malloc()
as a builtin, enabled upon seeing
#include <stdlib.h>
However, it would have been easy to mandate that there be a way to
turn it off, say via
#undef malloc
after the #include. Oh well, too late now.
--
Tim McDaniel
Applied Dynamics International, Ann Arbor, MI
Internet: mcdaniel%amara.uucp@mailgw.cc.umich.edu
UUCP: {uunet,sharkey}!amara!mcdanielmfriedma@oracle.com (Michael Friedman) (03/01/90)
In article <MCDANIEL.90Feb28121657@amara.amara.uucp} mcdaniel@amara.uucp (Tim McDaniel) writes: }gwyn@smoke.BRL.MIL (Doug Gwyn) writes: } You may #define your own malloc macro only if you don't #include <stdlib.h}. } ... } It would be better to use some name other than malloc for this macro. }Let me be more clear about an intended application. We'd like to have }ANSI C library semantics available on all our development platforms. You seem to be unnecessarily looking for trouble. Why does your memory allocation routine have to be given the same name as the ANSI C routine? Why not use ANSImalloc in all of your code and just #define it to malloc whenever you can? }For instance, free given a NULL argument could just do nothing (if the }platform's supplied free would abort in such a circumstance). We also }might like to have some sort of exception handling facility, or }manually record a stack trace. } }In such a case, we'd just like to have a wrapper around the "real" }function: } extern void * our_malloc(size_t); } #undef malloc } #define malloc(x) our_malloc(x) }where our_malloc does wrapperish stuff and then calls the real malloc }to do the real work. We'd set up "our_stdlib.h" with such }declarations. } }So, if we ever #include <stdlib.h}, even if I #undef malloc as a }precaution, I can't #define a new malloc? That's a bummer. (Since }we'll have an own_stdlib.h, there's a workaround, but it's still an }annoyance.) } }I assume the reasoning is that the compiler might have, say, malloc() }as a builtin, enabled upon seeing } #include <stdlib.h} }However, it would have been easy to mandate that there be a way to }turn it off, say via } #undef malloc }after the #include. Oh well, too late now. }-- }Tim McDaniel }Applied Dynamics International, Ann Arbor, MI }Internet: mcdaniel%amara.uucp@mailgw.cc.umich.edu }UUCP: {uunet,sharkey}!amara!mcdaniel -- The passing of Marxism-Leninism first from China and then from the Soviet Union will mean is death as a living ideology ... . For while there may be some isolated true believers left in places like Managua, Pyongyang, or Cambridge, MA ... - Francis Fukuyama
seanf@sco.COM (Sean Fagan) (03/01/90)
In article <MCDANIEL.90Feb27103334@amara.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >Are standard library names utterly and completely reserved, or can I >fake it with #define, as in > #define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__) You may not fake it. Well, actually, I think you can, but the results are "undefined" (I don't have a draft with me at the moment, so I can't be terribly specific). -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
drd@siia.mv.com (David Dick) (03/01/90)
karl@haddock.ima.isc.com (Karl Heuer) writes: >>[The names in the standard library are also reserved] >>Remember that you can no longer "roll your own" version of any >>of these routines. >You never could. The rules haven't changed in that respect; only the degree >of formalism in stating them. 1. Which rules are you speaking of that haven't changed? I thought that there weren't any rules before the new ANSI C standard. 2. We've used a number of different versions of malloc of our own and other's devising. David Dick Software Innovations, Inc. [the Software Moving Company(sm)]
karl@haddock.ima.isc.com (Karl Heuer) (03/01/90)
In article <5006@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: >In article <16021@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>In article <1990Feb23.184656.3110@siia.mv.com> drd@siia.mv.com (David Dick) writes: >>>Remember that you can no longer "roll your own" [standard library routine] >>You never could. > >Huh? Since when? You could always write your own strcpy (although things >might not have worked) I think you've just made my point. The old rule was: you can try to write your own malloc(); it might work or it might not. If you know enough about the internals of the implementation, you can probably write one that works. (After all, the library itself is largely written in C.) The new rule is: you can try to write your own malloc(), but the result is officially undefined--meaning it might work or it might not. If you know enough about the internals of the implementation, you can probably write one that works. >Since strcpy may not even *be* in the library, just in the compiler, that >makes it kinda hard to write your own. Even if it's a builtin, there has to be a spare copy in the library so that you can take its address%. (This is new to ANSI C; pre-ANSI C commonly implemented some routines as macros without providing a function version.) Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint ________ % With a few minor exceptions (assert(), setjmp()).
ghelmer@dsuvax.uucp (Guy Helmer) (03/02/90)
In article <MCDANIEL.90Feb28130347@amara.amara.uucp>, mcdaniel@amara.uucp (Tim McDaniel) writes: > gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > You may #define your own malloc macro only if you don't #include <stdlib.h>. > ... > It would be better to use some name other than malloc for this macro. Yes. Anyone other than the author might have a great time ( :-) ) deciphering code written this way. > Suppose I just want to put a wrapper around a system function. [...] > > In such a case, I would like to just do > extern void * my_malloc(size_t); > #undef malloc > #define malloc(x) my_malloc(x) > where my_malloc does wrapperish stuff and then calls the real malloc > to do the real work. I'd set up "my_stdlib.h" with such declarations. The original purpose for this idea seemed to be to use the preprocessor to put in calls to debugging code; if this is the case, why not write something like: #ifdef DEBUG_ON #define MALLOC(x) my_malloc((x), __FILE__, __LINE__) #else #define MALLOC(x) malloc(x) #endif If I were to read code written this way, I think I would understand a thousand times faster what the author's intent was. This also avoids all the trouble with library routines defined as macros, doesn't it? > Tim McDaniel > Applied Dynamics International, Ann Arbor, MI > Internet: mcdaniel%amara.uucp@mailgw.cc.umich.edu > UUCP: {uunet,sharkey}!amara!mcdaniel -- Guy Helmer ...!uunet!loft386!dsuvax!ghelmer Dakota State University Computing Services helmer@sdnet.bitnet Software Engineering: "'How to program if you cannot.'" - Dijkstra
karl@haddock.ima.isc.com (Karl Heuer) (03/02/90)
In article <5016@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: >In article <MCDANIEL.90Feb27103334@amara.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >>Are standard library names utterly and completely reserved, or can I >>fake it with #define, as in >> #define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__) The #define itself is legal (provided you first #undef any old one), but... >You may not fake it. [Undefined behavior if you do.] I believe that's correct. The problem is that some other routine from the standard header might be implemented as a macro that invokes malloc(), and could conceivably depend on some magic semantics that are not preserved by your clone. Elsewhere, Tim said: >Suppose I just want to put a wrapper around a system function. For instance, >free given a NULL argument could just do nothing (if my system's supplied >free would abort in such a circumstance). Wait a minute. If your system doesn't already do free() right, then it isn't ANSI conformant, and so it doesn't matter what the ANS says is legal. (As Doug has said, the Standard does not attempt to impose constraints on those implementations that do not obey the constraints of the Standard.) You are trying to *provide* ANSI semantics on what is otherwise a non-ANSI implementation. Go ahead and write your own wrapper functions (but keep in mind that they may have to be tailored to the system; in other words, you can't expect to do it portably). Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
henry@utzoo.uucp (Henry Spencer) (03/03/90)
In article <1990Feb28.221425.6430@siia.mv.com> drd@siia.mv.com (David Dick) writes: >>>[The names in the standard library are also reserved] >>>Remember that you can no longer "roll your own" version of any >>>of these routines. > >>You never could. The rules haven't changed in that respect; only the degree >>of formalism in stating them. > >1. Which rules are you speaking of that haven't changed? I thought >that there weren't any rules before the new ANSI C standard. Which means that you couldn't count on being able to override standard routines. Things not promised in the specs are not promised, period. That's what Karl meant: the all-bets-are-off nature of the situation has not changed, but the fact is now documented. >2. We've used a number of different versions of malloc of our own >and other's devising. If it works, it works. There is no promise that it will continue to do so, or that it will work on a different implementation. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/03/90)
In article <1990Mar2.172503.1567@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >That's what Karl meant: the all-bets-are-off nature of the situation >has not changed, but the fact is now documented. To be fair, it should be noted that the absence of any clear statement about the validity of supplanting library functions with one's own made it uncertain whether it was supposed to be allowed or not. Now that there is clear license for the implementation to do things that interfere with such usage, there is no longer any question about the validity of the practice. That's the sort of thing a standard is supposed to achieve.
seanf@sco.COM (Sean Fagan) (03/05/90)
In article <16064@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>In article <MCDANIEL.90Feb27103334@amara.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes: >>>Are standard library names utterly and completely reserved, or can I >>>fake it with #define, as in >>> #define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__) > >The #define itself is legal (provided you first #undef any old one), but... Is it? I was under the impression that the name 'malloc' was reserved completely. Or is it ok only because the define gets file scope (as opposed to external linkage, that is)? -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
karl@haddock.ima.isc.com (Karl Heuer) (03/06/90)
In article <5056@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: >In article <16064@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>[In an example `#define malloc(n) ...'] >>The #define itself is legal (provided you first #undef any old one), but... > >Is it? I was under the impression that the name 'malloc' was reserved >completely. I interpret this as having been legalized by the same decision that permitted "#define char ..." (which had ambiguous legality in an earlier Draft). The relevant section seems to be 2.1.1.2: preprocessing is done in translation phase 4; pp-tokens are converted into tokens and analyzed in phase 7. As I noted before, you may be breaking other rules by doing this (see my earlier article in this thread), but it should make it past the preprocessor. For example, it should be legal to have this #define as the last line in a translation unit. (Pretty useless, too.) Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
karl@haddock.ima.isc.com (Karl Heuer) (03/06/90)
In article <12273@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >To be fair, it should be noted that the absence of any clear statement >about the validity of supplanting library functions with one's own made >it uncertain whether it was supposed to be allowed or not... Actually, I was thinking more along these lines: whether or not it was *supposed* to be allowed, in actual practice it was not. For example, on most Unix systems, if you try to provide an alternate version of malloc() without also providing realloc() and free(), you'll get an error at link time, since the three functions are all in the same module. Thus, arbitrary library substitution does not always work. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint