Re: Documentation request for -ansi

[Nix <nix at esperi dot demon dot co dot uk>]

Claus Fischer <claus.fischer@intel.com> writes:

> Programs using erf, erfc, hypot, &c. from <math.h>, with -ansi, will
> treat them as returning integer, and will compute wrong stuff.
> 
> It has happened to me several times, even though I'm aware of that
> problem. The only indicator, -Wimplicit-function-declaration, is
> easily overlooked in a bunch of other warnings; and it doesn't mention

-Wall turns this on, too.

> that the implicit declaration has incorrect return type (int).

This is because all implicit declarations have int return type. GCC
doesn't know anything special about erfc() & friends, so it cannot warn
about these in particular; I don't think it should know about these in
particular, because if it does we'll end up having to implement similar
specialized warnings for every single function in the Standard.

The implicit declaration warning is enough, although IMHO where
functions in the Standard are concerned it should be an error with -ansi
(as it *is* erroneous to use such names without including the
appropriate header file or declaring the correct prototype, at least in
C99, and I'd be amazed if this wasn't true of C89 as well). Of course,
it should only be an error with the appropriate -std= option.

> On a higher level, the problem comes from the mis-organization of
> (Unix) header files: If those prototypes weren't in an ANSI library
> (math.h) but in a separate library, it would not happen.

C99 *requires* them to be there, though, so this is C, not just Unix.

Also, erfc() and friends are mathematical functions; <math.h> is the
logical place for them.

> With <math.h>, it is not obvious in the code whether I want to
> include the ANSI version of the header or the extended version.

This is what __STDC_VERSION__ is for.

> What if <cmath> includes <math.h>; will it use the C89 or C99 version
> of the headers?

I'd hope C89, because the C++ Standard does not reference a version of
the C Standard that defines erfc(). But this is a library issue and
unrelated to GCC.

>     It's all documented, but nobody reads documentation, at least not
>     to that fine-grained level of interpreting the paragraph about
>     __STRICT_ANSI__ as `my erfc calls will silently fail'.

It's not silent, with -Wall, or with -W{error-}implicit-function-
declaration. (IMHO -Wimplicit-function-declaration should be turned on
by -ansi...)

>     ATTENTION: Note that -ansi will cause several non-ANSI functions
>     in <math.h> to be treated as integer functions; this might cause

Not necessarily true of all C libraries, so the GCC documentation cannot
really state this.

>     your programs to compute wrong results. Always use the -Wall or
>     -Wimplicit-function-declaration switches in conjunction with
>     -ansi, and pay attention to messages like:
>        warning: implicit declaration of function `erfc'

Why does the documentation need to contain messages enjoining people to
read the warnings? That's what the warnings are for!

> (2) C Library
> 
>     With -ansi, the C library should not resolve the symbols of erfc.
>     Not easily doable, and probably not worth doing.

... and not doable from within GCC anyway.

> (3) Special prototypes
> 
>     With support from the compiler, one could pre-define prototypes
>     with a special return type (let's call it warn_int):
> 
>     warn_int erf(warn_int arg);

*sick*

If this was implemented --- and I don't think it should be --- it should
be implemented as a function attribute.

However, unfortunately, this attribute would only kick in if the
prototype was seen, in which case it would automatically not come into
effect. (And I'd be rather worried if I saw that warning when compiling
code for a freestanding target, too, as erf() could do something quite
different there.)

Or do you mean that GCC should have special knowledge of lots of
semi-standardized stuff from <math.h>, even though they are not
builtins?

That way lies madness, I fear.

>     Such prototypes would be defined for all (non-int) functions in
>     libc which are not ANSI, and would be superseded by the real
>     prototype.

Impossible to do from within GCC, again; GCC != libc; GCC is used with
many libcs.

> I don't like any of these solutions very well, but I can't think
> of a better one.

Turn on -Wimplicit-function-declaration with -ansi. (The patch to force
it on by default is a one-liner; you can probably submit it even if you
don't have a copyright assignment on file.)

> The thing to understand here is that the situation is different
> for erfc than for functions not in libc, where absence of the
> function can be detected very easily.

GCC does not control the libc. Except where builtins are concerned, GCC
treats functions in libc just like any other functions.

-- 
> ... knowing the alignment of Orcs in AD&D.
Doubleword.
  --- David Jacoby and Greg Andrews in the Monastery