Bug 10167 - ieee_1003.1-[3.2/3.3 regression] 2001 locale specialisations on a RedHat8.0/glibc-2.3.2-4 system
|
Bug#:
10167
|
Product: gcc
|
Version: 3.2
|
|
Host:
|
Target:
|
Build:
|
|
Status: RESOLVED
|
Severity: normal
|
Priority: P3
|
|
Resolution: FIXED
|
Assigned To: unassigned@gcc.gnu.org
|
Reported By: andrew.pollard@brooks.com
|
|
Component: libstdc++
|
Target Milestone: ---
|
|
Summary: ieee_1003.1-[3.2/3.3 regression] 2001 locale specialisations on a RedHat8.0/glibc-2.3.2-4 system
|
|
Keywords:
|
|
Opened: 2003-03-20 14:56
|
I have just upgraded my RedHat Linux 8.0 system to the latest Redhat glibc
(2.3.2-4), and I've spotted a problem with
libstdc++-v3/include/bits/codecvt.h and
libstdc++-v3config/locale/ieee_1003.1-2001/codecvt_specializations.h
I assume that the switch to glibc-2.3.2-4 has enabled this specialisation.
I have not seen the problem prior today.
codecvt.cxx:
--------------------------------------------
namespace error {}
#include <ios>
--------------------------------------------
% g++32 -c codecvt.cxx
....
/usr/local/gcc-3.2.3-20030320-i686-pc-linux-gnu/include/c++/3.2.3/i686-pc-linux-gnu/bits/codecvt_specializations.h:424:
use
of namespace `error' as expression
Basically, bits/codecvt.h has an 'enum result' in codecvt_base which is used as
a return result from a lot of the methods in __codecvt_abstract_base. The uses
within ieee_1003.1-2001/codecvt_specializations.h are not fully qualified, so
gcc-3.2.3-20030320 gets confused about using a namespace as an expression.
Similarly for the 'ok', 'partial' and 'noconv' enum values.
I assume gcc-3.3 and gcc-3.4 will have the same problem since they have the
same enum.
Release:
gcc-3.2.3-20030320-cvs
Environment:
Redhat8.0/Glibc-2.3.2-4
Fix:
Qualify the uses of the codecvt_base::result 'ok', 'partial', 'error', 'noconv' enums in the ieee_1003.1-2001/codecvt_specializations.h file
either codecvt_base::error, or this->error seem to work.
Alternatively, uglify the enum values, eg __error, __ok, etc, since the __ things are reserved for the implementation
State-Changed-From-To: open->analyzed
State-Changed-Why: Cannot possibly affect 3.4, due to this commit:
2003-02-06 Petur Runolfsson <peturr02@ru.is>
DR 75
DR 305
PR libstdc++/9028 (partial)
PR libstdc++/9224
PR libstdc++/9246
PR libstdc++/9247
Benjamin, at this point in the release cycle of 3.3 we
had better only fully qualifying (error as
codecvt_base::error, etc.), instead of fully backporting
Pétur's rewrote, I think. Do you agree?
Thanks, Paolo.
From: Benjamin Kosnik <bkoz@redhat.com>
To: paolo@gcc.gnu.org, Andrew.Pollard@brooks.com, bkoz@redhat.com,
gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Cc: paolo@gcc.gnu.org, Andrew.Pollard@brooks.com,
gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: libstdc++/10167: ieee_1003.1-[3.2/3.3 regression] 2001 locale
specialisations on a RedHat8.0/glibc-2.3.2-4 system
Date: Thu, 20 Mar 2003 20:50:18 -0600
> Benjamin, at this point in the release cycle of 3.3 we
> had better only fully qualifying (error as=20
> codecvt_base::error, etc.), instead of fully backporting
> P=E9tur's rewrote, I think. Do you agree?
> Thanks, Paolo.
Yes, just make sure it passes make check-abi.
thanks!
benjamin
State-Changed-From-To: analyzed->closed
State-Changed-Why: Fixed for 3.3.