Red Hat Bugzilla – Bug 98047
LTC3381 - c++locale.h redefines default arugment.
Last modified: 2007-11-30 17:06:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Description of problem:
around line 56, a template function is defined with default argument. This
function is refined in locales_facets.tcc
According to the C++ Standard, duplicate definition of default argument is not
allowed. I believe this is a bug in the GNU GCC header files.
There is also a bug in GCC, becuase according to the ISO C++ Standard sector
8.3.6 paragraph 4, it should not accept this code.
The testcase defparm3.C fails to compile (which is correct) when no template is
g++ defparm3.C -c
defparm3.C: In function `int foo(int)':
defparm3.C:7: default argument given for parameter 1 of `int foo(int = -1)'
defparm3.C:2: after previous specification in `int foo(int = -1)'
The testcase defparm.C, even there is a redefined default arugment, GCC fails to
catch it as an error.
The c++locale.h header file should be changed such that the default argument is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Compile the included defparm.C file to see GCC's incorrect accepting of
2.Since GCC is incorrectly accepting the C++locale.h file, the bug in
C++locale.h can only be seen when GCC is fixed.
Actual Results: GCC incorrectly accept code that's not ISO C++ compliance.
Expected Results: GCC should give error on C++locale.h.
C++locale.h should not redefine default arugment.
Created attachment 92617 [details]
shows GCC incorrectly accpet template with default arugment redefined.
Created attachment 92618 [details]
Show GCC correct flag the error with redefined default arugment in non-template function.
*** Bug 98868 has been marked as a duplicate of this bug. ***
Mainline gcc and gcc-3_3-branch sources don't have the issue with c++locale.h.
Perhaps previous versions did have the __convert_from_v default argument in two
places: since this has been replaced in mainline and on gcc-3_3-branch it's no
longer an issue.
I've tried to compile above with gcc-3_2-rhl-branch and gcc-3_3-branch and
mainline gcc, and all give me the proper error, so I don't know what's up.
Perhaps this is specific to ppc64 (seems unlikely?)
I have changed gcc-3_2-rhl8-branch to avoid the problem there.
As for the missing pedwarn, it is missing on all of gcc-3_2-rhl8-branch,
gcc-3_3-branch and HEAD.
Benjamin, you get any errors compiling:
------- Additional Comments From firstname.lastname@example.org(prefers email via email@example.com) 2003-05-08 18:26 -------
Do we have an estimate of when this will be fixed in RHEL? Thanks.
The bug in the headers is fixed in gcc-3.2.3-10 and later (ie. already
in beta1 for example). Are you talking about the headers or the lack of diagnostics?
------- Additional Comments From firstname.lastname@example.org(prefers email via email@example.com) 2003-07-08 11:49 -------
I was talking about the headers. Closing this as FIXED_BY_DISTRO. Thanks Jakub!
What |Removed |Added
------- Additional Comments From firstname.lastname@example.org 2003-08-09 14:16 -------
Is this problem fixed? Or can someone answer Red Hat?
------- Additional Comments From email@example.com 2003-08-09 15:51 -------
This bug is fixed in beta1 or RHEL, but bugzilla won't let me add comment
or update the status. Can you please close this defect for me? Thanks.
C/C++ Compiler/Runtime Development
IBM Toronto Laboratory
firstname.lastname@example.org (905) 413-2733 C2/KD2/8200/MKM