Test for function existence?
David Mathog
existence of a function in a particular compiler implementation that
does not depend upon the definition of an associated preprocessor
variable? For instance chown() is often not implemented on some
platforms, so what I'm looking for is an expression like:
#if MAGIC_HERE(chown)
/* use chown() somehow */
#else
/* do nothing */
#endif
I already looked in the FAQ and didn't see anything, but given the size
of that document, I could have missed it.
Assuming there is no such method, would it not be convenient to
implement it? I understand that when generating object files the
compiler will not necessarily know whether or not a particular function
being called exists, that won't be determined until the link phase.
However, it seems resonable that the compiler should, or at least could,
have a list available of all the functions in its own libraries, making
such a test possible.
Thanks,
David Mathog
Kenny McCormack
Isn't this basically what "autoconfig" systems are for?
You run a little test to see if the implementation has the feature, then
insert stuff in the source code that indicates the result.
ImpalerCore
> Is there a standard, or at least common, method for testing for the
> existence of a function in a particular compiler implementation that
> does not depend upon the definition of an associated preprocessor
> variable? For instance chown() is often not implemented on some
> platforms, so what I'm looking for is an expression like:
The main method of doing this is using something like autoconf and
generating a test code fragment that is compiled and the result used
to update a configuration header file. These test code fragments are
executed when running ./configure, which generates a config.h that has
statements like the following.
#if !defined(HAVE_CHOWN)
# define HAVE_CHOWN 1
#endif
If chown does not exist, then it will comment out the '# define
HAVE_CHOWN 1' line. You're still checking a preprocessor variable,
but it isn't derived from a nest of compiler and platform specific
defines.
> #if MAGIC_HERE(chown)
> /* use chown() somehow */
> #else
> /* do nothing */
> #endif
>
> I already looked in the FAQ and didn't see anything, but given the size
> of that document, I could have missed it.
>
> Assuming there is no such method, would it not be convenient to
> implement it? I understand that when generating object files the
> compiler will not necessarily know whether or not a particular function
> being called exists, that won't be determined until the link phase.
> However, it seems resonable that the compiler should, or at least could,
> have a list available of all the functions in its own libraries, making
> such a test possible.
I think the inertia of the autoconf system would make it very
difficult to motivate a compiler vendor to implement it. They'll
probably tell you to use autoconf, or write your own test in a
makefile.
Best regards,
John D.
> Thanks,
>
> David Mathog
David Mathog
> On Mar 5, 11:27 am, David Mathog<mat...@caltech.edu> wrote:
>> Is there a standard, or at least common, method for testing for the
>> existence of a function in a particular compiler implementation that
>> does not depend upon the definition of an associated preprocessor
>> variable? For instance chown() is often not implemented on some
>> platforms, so what I'm looking for is an expression like:
>
> The main method of doing this is using something like autoconf and
> generating a test code fragment that is compiled and the result used
> to update a configuration header file.
I knew about autoconf, and yes, that works. That tells us there are
existing tools to work around this issue, but it seems to me the proper
place to resolve the common issue of "C compiler does not provide
function X" is in the C preprocessor, not in an external program.
I mean, is it good language design that we have to run autoconf and then
still have to use:
#if HAVE_CHOWN
or to use what is essentially the same logic in the program, but test
directly for function existence with the preprocessor? Seems to me it
would be reasonable for a compiler to not only be able to identify
unresolved variables, but also references to unimplemented functions.
Perhaps I'm being naive, but it seems like a simple thing to build into
a compiler:
1. Define a test for function existence, for instance "implemented()"
2. List all of the compiler supplied functions.
3. At compile time have the compiler read that list the first time it
sees one of these:
#if implemented(chown)
4. Apply the preprocessor logic as appropriate.
Then we could eliminate the external program, which might not run on the
target platform in any case.
No matter which of these is used, the programmer still needs to be aware
of platform differences.
Regards,
David Mathog
David Mathog
> Perhaps I'm being naive, but it seems like a simple thing to build into
> a compiler:
>
> 1. Define a test for function existence, for instance "implemented()"
> 2. List all of the compiler supplied functions.
> 3. At compile time have the compiler read that list the first time it
> sees one of these:
>
> #if implemented(chown)
Another way of doing this might be to build it onto the existing
prototype handling code. However that might be problematical because it
requires prototypes to be accumulated while the preprocessor is running,
and I suspect that prototype definitions are accumulated on a later pass
of the compiler. Anyway, assuming prototype definitions are stored in
some way while the preprocessor runs:
1. Define a test for a prototype definition of a function "prototype()"
2. When the preprocessor hits:
#if prototype(chown)
Check the list of prototypes and return true if there is a
matching entry.
So long as the compiler did not include prototypes for unimplemented
functions this should work nicely for the intended purpose.
Regards,
David Mathog
Nobody
>> The main method of doing this is using something like autoconf and
>> generating a test code fragment that is compiled and the result used
>> to update a configuration header file.
>
> I knew about autoconf, and yes, that works. That tells us there are
> existing tools to work around this issue, but it seems to me the proper
> place to resolve the common issue of "C compiler does not provide
> function X" is in the C preprocessor, not in an external program.
You're overestimating the preprocessor. It's tokenising rules are designed
to match C syntax, but its connection to C ends there.
> I mean, is it good language design that we have to run autoconf and then
> still have to use:
>
> #if HAVE_CHOWN
>
> or to use what is essentially the same logic in the program, but test
> directly for function existence with the preprocessor? Seems to me it
> would be reasonable for a compiler to not only be able to identify
> unresolved variables, but also references to unimplemented functions.
It would be reasonable for a compiler, but not for a preprocessor.
> Perhaps I'm being naive, but it seems like a simple thing to build into
> a compiler:
Compiler, yes. Preprocessor, no.
The C preprocessor isn't fundamentally different to other preprocessors,
e.g. m4. It just processes text. It doesn't "understand" the text it
processes beyond preprocessor directives and macro syntax.
In terms of what autoconf is used for, the existence of declarations is
only part of the problem. autoconf tests often don't just test for the
existence of a function, but perform multiple tests with different
compilation and/or linking flags in order to detect whether specific flags
are required in order for the function to be available. That isn't
something that can be built into the preprocessor or compiler.
Gordon Burditt
>existence of a function in a particular compiler implementation that
>does not depend upon the definition of an associated preprocessor
>variable?
Unless you count autoconf and similar systems, no.
>For instance chown() is often not implemented on some
>platforms, so what I'm looking for is an expression like:
Is chown() supplied by the OS or the compiler? It is *not* supposed
to be declared in Standard C header files and it's supposed to be
allowed to write your own.
>#if MAGIC_HERE(chown)
> /* use chown() somehow */
>#else
> /* do nothing */
>#endif
What does this code do?
#if function_exists(chown)
/* define it again */
int chown(int fd, int uid, int gid)
{
... guts of function here ...
}
#else
/* do nothing, leaving it undefined */
#endif
Does it define a duplicate function or make references to chown() undefined?
>Assuming there is no such method, would it not be convenient to
>implement it?
No, unless you can retrofit all existing compilers without their
owners noticing. That includes gcc 1.x .
>I understand that when generating object files the
>compiler will not necessarily know whether or not a particular function
>being called exists, that won't be determined until the link phase.
That's a *big* problem. Even worse is that it's easy to write code
that if the function exists, then it doesn't, and if it doesn't
exist, then it does. By accident, even.
Also, what if it exists, but it's *NOT* a function? There's nothing
prohibiting an implementation from using a function-like macro to
define, say, fopen(name, mode) to be _fopen_no_mutex(name,mode) or
_fopen_with_mutex(name,mode) depending on whether threading is being
used or not.
>However, it seems resonable that the compiler should, or at least could,
>have a list available of all the functions in its own libraries, making
>such a test possible.
So, what *ARE* the compiler's "own libraries"? Does it include (if
they are present) termcap libraries? X11 libraries (which kind?
X386 or Xorg)? OpenSSL libraries? Using this magic to see if certain
Standard C functions exist is kinda pointless. Nearly everyone
has those. Those that don't probably won't have your compiler magic.
I seem to have over 750 optional libraries installed. Quite a few
of them overlap.
Note that some of the compiler's "own libraries" WILL NOT BE USED
when compiling standalone programs (like kernels, boot code, etc.)
Note also that just because function A exists and function B exists,
it *doesn't* mean that you can use function A and function B in the
same code, because those functions might be in mutually-incompatible
versions of the same library. Yes, I've had up to 6 sets of X386
and Xorg X libraries around at the same time.