AC_CHECK_FUNCS and the "char" return value

[Micah Cowan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks,

A Wget user has been trying to get current development Wget code to
build on various systems, and has run into a snag, at this time, on
Tru64. I realize this is an old system, but the issue is that the
compiler on Tru64 is complaining about something that is, in fact broken.

This may be a problem without a real solution: what we're doing with
AC_CHECK_FUNCS is, plain and simple, a horrible hack. It's bad enough to
be invoking functions without prototypes, a technique that probably
won't be sustainable long-term; but lying about the return type was
bound to bite us somewhere, and here it does.

Obviously, invoking functions to test them "the right way" adds much
complexity to autoconf and/or configure.ac specs, so I'm not really
proposing something, but I figure folks should be aware that it does
cause problems, if you're not currently.

- -Micah

Steven M. Schweda wrote:

>> IIRC, it shouldn't have been using siggetmask, because it was supposed
>> to trigger something else with the configure script. Or something? :)
> 
>    Something.  Apparently, it got these partly wrong:
> 
> /* Define to 1 if you have the `sigblock' function. */
> #define HAVE_SIGBLOCK 1
> 
> /* Define to 1 if you have the `sigsetjmp' function. */
> /* #undef HAVE_SIGSETJMP */
> 
> It really does have sigsetjmp(), but won't use it, and the alternative
> in src/utils.c involves siggetmask().  The problem seems to be a
> combination of a sloppy test program and a fussy compiler:
> 
>    configure line 13279 (...):
> 
> [...]
> /* Override any GCC internal prototype to avoid an error.
>    Use char because int might match the return type of a GCC
>    builtin and then its argument prototype would still apply.  */
> #ifdef __cplusplus
> extern "C"
> #endif
> char $ac_func ();
> [...]
> 
> The "char $ac_func ();" leads to this in config.log:
> 
> configure:13251: checking for sigsetjmp
> configure:13307: cc -o conftest -g -I/usr/local/include  conftest.c  >&5
> cc: Error: conftest.c, line 94: In this statement, the declaration for
> the prototyped intrinsic function "sigsetjmp" is incorrect: the declared
> return type of "char" is not consistent with the expected type of "int".
> (intrinsicdecler)
> char sigsetjmp ();
> -----^
> configure:13313: $? = 1
> 
>    Luckily or not, there are more compilers out here than GCC, and this
> one appears to be harder to fool.  The official error description is:
> 
> INTRINSICDECLER
> 
>   Message        <Context> the declaration for the prototyped
>                  intrinsic function "<name>" is incorrect:  <problem>.
> 
>   Description    A function that could be handled internally by the
>                  compiler and requires a prototype, has been declared
>                  with a prototype that does not agree with what the
>                  compiler expected to see.  The function might be
>                  intended as a similarly-named replacement for the
>                  compiler-known function, or the prototype might be
>                  incorrect.  The source must be modified to specify
>                  the intended behavior.
> 
>   User Action    If the function is intended to refer to the
>                  compiler-known routine, the appropriate header file
>                  should be included in the source.  Alternatively, the
>                  prototype could be modified as specified in the error
>                  message.  If the function is intended to be a
>                  replacement for the compiler-known routine, disable
>                  the intrinsic version by specifying "#pragma
>                  function(function_name)" in the source file.
> 
> 
>    With an "int" declaration, it's not thrilled, but it is happier (and
> happy enough):
> 
> urtx# diff conf_sig.c conf_sig_i.c
> 94c94
> < char sigsetjmp ();
> ---
>> int sigsetjmp ();
> 
> urtx# cc -o conf_sig_i -source_listing -g -I/usr/local/include conf_sig_i.c
> cc: Info: conf_sig_i.c, line 105: In this statement, an apparent invocation 
> of i
> ntrinsic function "sigsetjmp", the number of specified arguments is 0 instead 
> of
>  the expected 2.  It will be treated as an ordinary external call. 
> (intrinsiccal
> l)
> return sigsetjmp ();
> -------^
> urtx# echo $?
> 0
> 
> 
>    Despite the comment explaining why "char" is better, a recent GCC
> seems to be pretty happy either way:
> 
> urtx# gcc -o conf_sig_g -g -I/usr/local/include conf_sig.c
> urtx# gcc -o conf_sig_i_g -g -I/usr/local/include conf_sig_i.c
> urtx# gcc --version
> gcc (GCC) 4.3.0
> Copyright (C) 2008 Free Software Foundation, Inc.
> [...]
> 
> I can't say what all the older ones might do.  Or fussier checking
> options.
> 
>    With this compiler, a separate "int"-type test would be better for
> sigsetjmp().  Perhaps an alternate test if the "char"-type test fails? 
> Everything's complicated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIErzw7M8hyUobTrERAgxWAJ9EEVVG2tpxbkn1/nheRfTUimO8bACfbNxo
FGUU/mtnH97+YqqCokqrkPY=
=nHTl
-----END PGP SIGNATURE-----