This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: const inconsistency in g++ 2.95.2 sparc-sun-solaris2.7
- To: Tom Ace <crux at QNET dot COM>
- Subject: Re: const inconsistency in g++ 2.95.2 sparc-sun-solaris2.7
- From: Alexandre Oliva <aoliva at cygnus dot com>
- Date: 06 Apr 2000 16:35:08 -0300
- Cc: gcc-bugs at gcc dot gnu dot org
- Organization: Cygnus Solutions, a Red Hat Company
- References: <200004061910.MAA02372@localhost>
On Apr 6, 2000, Tom Ace <crux@QNET.COM> wrote:
> I've noted what seems to be an inconsistency in gcc.
Nope. If it's an inconsistency, it's in the C++ Standard. But I
don't think it is.
> test.cc:4: assignment to `char *' from `const char *' discards qualifiers
> char *c;
[snip]
> void t3(int x) { c = x ? "t" : (char *) 0; }
The type of `"t"' is `const char [2]', so, after array-to-pointer
decaying, it would be `const char*'. However, for backward
compatibility, the C++ Standard allows a string literal to decay to
non-const `char*', but this conversion is deprecated. That's why `c =
"t"' works. But when the string literal appears in a ?: expression,
there's no reason why it should decay to `char*' instead of `const
char*'. Furthermore `(char*)0' can be implicitly const-qualified, so
the result type of the ?: expression is `const char*'. The
work-around is to explicitly cast the string literal to `char*'. But
The Right Thing (TM) is to const-qualify `c'.
--
Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me