This is the mail archive of the gcc-bugs@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]
Other format: [Raw text]

[Bug libstdc++/14608] <iostream.h> nukes isfinite macro from <math.h>


------- Additional Comments From gdr at integrable-solutions dot net  2004-03-16 19:52 -------
Subject: Re:  New: <iostream.h> nukes isfinite macro from <math.h>



Short answer for this PR:  Use -D_GLIBCXX_USE_C99_MATH if you want to
retain C99 random bits consistently.


Longer answer:

"zack at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I will attach two test cases to this bug.  The first test case was
| provided to me by a customer; it is a cut-down version of a larger
| piece of code that did need both <math.h> and <iostream.h>.  The
| observed problem is that if both these headers are included (in
| either order) in the same translation unit, the isfinite macro (part
| of C99) is not available to subsequent code.  If only <math.h> is
| included, then isfinite is available. 

The bug is that isfinite() is at all available *as macro*, when
<math.h> is included.  But, that is a general problem in that we don't
have control over <math.h> and so we don't remove sneaky macros as we
should all the time. 

First of all, C++ explicitly permits any standard header that is not
inherited from C to include any other standard header -- that is
hardly avoidable.  <iostream.h> is not a standard header but is
provided as a courtesy (see appendix D of the C++ standard) and is, in
fact, an inclusion of <iostream> followed by a series of
using-declarations -- as is done for C inherited headers <xxx.h> as
mandated by the C++ standard.  <iostream> (transively) includes
<cmath> for whatever reasons.  <cmath> turn functional macros into
functions, and by default provides only C90 functions.

However, you may specify -D_GLIBCXX_USE_C00_MATH if you want to retain
C99 random bits.

| The second test case is the workaround that I found for GCC 3.3.3.
| It does not work with GCC 3.4, even with the obvious s/GLIBCPP/GLIBCXX/.
| 
| It should be noted that HPUX's libc does not implement all of C99,
| but it *does* provide all of the C99 math functions - but isfinite()
| and friends are only macros (which is allowed by C99).  I don't know
| what the C++ standard specifies in this area but it seems to me that
| QoI dictates that C++ programs be able to use all the
| system-provided library facilities. 

Discussing "dictated" behaviour without looking at what the C++
standard says is a good recipe for frustration and waste of time.

The C++ committee is considering adding  -- to the first Technical
Report (not a standard in its strict sense) -- modified versions of
the myriad of functions C99 added to C90.  PJ. Plauger made a report
early in 2002 and followed up with

  http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1503.txt

and more corrections in subsequent mailings.  
Turning C99 sneaky functional macros into plain functions are general
requirements of C++ and also recommended in the above proposal.
The implementation of V3 is in adequation with those recommandations.

I propose to close this PR.  The only bug here is that we don't remove
macros consistently, but that is a known problem we don't have a
solution for right now.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608


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