This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Documentation request for -ansi



Repetitive trauma from -ansi
============================

This probably happens mostly to numerics folks.

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
that the implicit declaration has incorrect return type (int).

The use of -pedantic is documented as `reject all programs that use
forbidden extensions.', however that doesn't mean library extensions.

The problem here is that the programs compile and link successfully
but produce (silently) wrong results.

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.

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.


Finally C++/C has the following oddity:
          erfc in <math.h>/<cmath>?
C89       NO
C99       YES
C++88     ??? (presently no)

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


Solutions
=========


(1) Documentation

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

    I think this deserves some strong wording in the documentation
    of -ansi, e.g.:


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


(2) C Library

    With -ansi, the C library should not resolve the symbols of erfc.
    Not easily doable, and probably not worth doing.
    Also people don't always use the same flags for linking.


(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);

    When the compiler comes to using a function with a signature like
    that it would issue a special warning, very loud, and it always
    gives this warning when you use -ansi (not just with -Wall).

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


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

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.

Claus

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]