Bug 179525 - bad nesting of macros in mathcalls.h
Summary: bad nesting of macros in mathcalls.h
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 181409
TreeView+ depends on / blocked
 
Reported: 2006-02-01 03:29 UTC by Chris Quenelle
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: RHBA-2006-0510
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-10 21:34:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0510 0 normal SHIPPED_LIVE glibc bug fix update 2006-08-09 04:00:00 UTC

Description Chris Quenelle 2006-02-01 03:29:29 UTC
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-02-01 04:26:09 UTC
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 17:18:33 UTC
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 21:34:16 UTC
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.