Bug 179525 - bad nesting of macros in mathcalls.h
bad nesting of macros in mathcalls.h
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks: 181409
  Show dependency treegraph
 
Reported: 2006-01-31 22:29 EST by Chris Quenelle
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0510
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:34:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Quenelle 2006-01-31 22:29:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.10) Gecko/20050720 Firefox/1.0.6

Description of problem:
We are porting our compilers to linux, and trying to use
the glibc headers (where we can) in combination with
our compiler (which is NOT g++).

Here is an issue we discovered:

  /usr/include/bits/mathcalls.h:277 has this

277: #if defined __USE_MISC || defined __USE_XOPEN_EXTENDED || \
     defined __USE_ISOC99
    __BEGIN_NAMESPACE_C99
    ...
    #endif

later (line 

300: #ifdef __USE_ISOC99
...
356: __END_NAMESPACE_C99
...
    #endif

 
It's a bad idea to have an open-scope statement protected
by different macros than the corresponding close.


At the top of mathcalls.h the NAMESPACE macros are closely nested
inside the #ifdefs.  But later in the file, the NAMESPACE macros
start to get separated by more distance, and eventually (around line 300)
they are covered by different #ifdef macros, which can sometimes
result in mismatched open and close braces. 

I can't see an easy suggestion for which way to group the
various guards in this file, but they need to be made
consistent somehow.


Version-Release number of selected component (if applicable):
glibc-headers-2.3.4-2

How reproducible:
Always

Steps to Reproduce:
You can see the bug by inspecting the header file.

% more t.cc

// This is turned on by #include <cassert> (for example)
// as opposed to #include <assert.h>
#define _GLIBCPP_USE_NAMESPACES 1

#include <math.h>

template<class T>  class foo {
   T bar;
};
foo<int> ff;

int main()
{
  return 0;
}

% g++ -U_GNU_SOURCE -c t.cc
t.cc:8: error: template with C linkage
t.cc:16: error: expected `}' at end of input
t.cc:16: error: expected `}' at end of input
t.cc:16: error: expected `}' at end of input



Additional info:
Comment 1 Chris Quenelle 2006-01-31 23:26:09 EST
g++ seems to use a different mechanism for controlling the C++
bracketing code.  It doesn't seem to set _GLIBCPP_USE_NAMESPACES.

For example see:
/usr/include/c++/3.4.3/cmath

It includes bits/c++config.h:

/usr/include/c++/3.4.3/i386-redhat-linux/bits/c++config.h

This header sets up a lot of macros, but it doesn't set
_GLIBCPP_USE_NAMESPACES.  I'm not sure why.

Comment 5 Bob Johnson 2006-04-11 13:18:33 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.
Comment 10 Red Hat Bugzilla 2006-08-10 17:34:16 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0510.html

Note You need to log in before you can comment on or make changes to this bug.