Test for function existence?

[David Mathog]

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:

#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]

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:

#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.

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.

 

[David Mathog]

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]

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.