This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Documentation request for -ansi
- To: gcc at gcc dot gnu dot org
- Subject: Documentation request for -ansi
- From: Claus Fischer <claus dot fischer at intel dot com>
- Date: Wed, 21 Jun 2000 10:31:39 -0700
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