[Bug c++/20475] static_cast falsely allows const to be cast away
--- Comment #12 from manu at gcc dot gnu dot org 2008-08-06 18:42 --- This always produces a warning by default now. Thus FIXED. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-16 09:07 ---
Subject: Re: static_cast falsely allows const to be cast away
schlie at comcast dot net [EMAIL PROTECTED] writes:
| --- Additional Comments From schlie at comcast dot net 2005-05-16 05:07
---
| (In reply to comment #7)
| Subject: Re: static_cast falsely allows const to be cast away
| That is your view. However, not because GCC implements the ISO C++
| view of types, means that GCC has a narrow view of a type is. I
| suspect that part of your speculation is based on unfamiliarity with
| both the C++ type system and the GCC internal notion of types.
|
| - but apparently inadequate to express the necessary differentiation between
| constant and literal objects, as needed to be tracked by a compiler for
| these languages?
I don't think the distinction is necessary -- I can see arguments why
people would want it, but it is not necessary. You're speaking of
literals but seem to forget that 0 and 0+0 should be put in the
same category though the latter is not a literal. So, literal is not
the right thing. The notion used in C++ is constant expressions, that
directly leads to const objects.
| | A literal string is not simply a 'const char [N]' object, as a
| | literal value may not be specified as a target of an assignment,
| | directly or indirectly though a pointer cast to a non-const object
| | reference, unlike as a plain old 'const' objects may be.
|
| But, a plain old 'const' object cannot be a target of an assignment.
| There is no different there -- and certainly static does not imply a
| difference there -- so the basis of your argument seems fragile to
| begin with.
|
| - subtle possibly, but not fragile; the following simple program illustrates
without being insulting, I don't believe it is subtile -- it just
emphasizes some unfamiliarity with the C++ type system. Once you
start adding a type qualifier, you have to spell out clearly its
interaction with the type system (including overload resolution) and
separate compilation.
| the problem, where if hypothetically 'literal' were a valid qualifier,
| then the problem would be easy to solve, and also flexibly enable the
that solve is only apparent. It introduces a whole can of worms you
seem to handwave.
| definition of functions which accept and return references to literals,
| as being distinct from const, where const means simply not writeable
| presently, not necessary never (i.e. can't ever assign to references,
| which is what literal semantics would seem to dictate.):
But const in C++ does not mean no writeable. This is another
symptom of unfamiliarity with the C++ type system.
| #include stdio.h
|
| int main (void)
| {
|// non-const pointers to literals should at least warn,
|// and assignments to literals should generate an error.
|char *cp = (a); // compiles without warning/error (literal*)?
I have a warning on my system -- what are you using?
| // ((char *)cp)[1] = 't';// compiles without warning/error - bus error!
because you shall not. The rule is quite simple : thou shalt not
modify a const object. No but, no if. Period.
|printf(cp); // dies above if uncommented, otherwise (a)
|
|char ca[4] = (b); // compiles without warning/error.
|((char *)ca)[1] = 't';// compiles without warning/error.
|printf(ca); // outputs (t), as expected.
because of initialization of the array.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-16 13:25
---
(In reply to comment #9)
Subject: Re: static_cast falsely allows const to be cast away
Gabriel Dos Reis writes:
| --- Additional Comments From schlie at comcast dot net 2005-05-16
| (In reply to comment #7)
| Subject: Re: static_cast falsely allows const to be cast away
| That is your view. However, not because GCC implements the ISO C++
| view of types, means that GCC has a narrow view of a type is. I
| suspect that part of your speculation is based on unfamiliarity with
| both the C++ type system and the GCC internal notion of types.
|
| - but apparently inadequate to express the necessary differentiation
| between constant and literal objects, as needed to be tracked by a
| compiler for these languages?
I don't think the distinction is necessary -- I can see arguments why
people would want it, but it is not necessary. You're speaking of
literals but seem to forget that 0 and 0+0 should be put in the
same category though the latter is not a literal. So, literal is not
the right thing. The notion used in C++ is constant expressions, that
directly leads to const objects.
- to me constant expression is an oxymoron, as any expression which can't
be resolved to a literal value prior to program execution is a runtime
computed expression. (so all expressions resolve at compile time to
either literals or otherwise, where the otherwises may result in
'const' objects and/or references or not.
| | A literal string is not simply a 'const char [N]' object, as a
| | literal value may not be specified as a target of an assignment,
| | directly or indirectly though a pointer cast to a non-const object
| | reference, unlike as a plain old 'const' objects may be.
|
| But, a plain old 'const' object cannot be a target of an assignment.
| There is no different there -- and certainly static does not imply a
| difference there -- so the basis of your argument seems fragile to
| begin with.
|
| - subtle possibly, but not fragile; the following simple program illustrates
without being insulting, I don't believe it is subtile -- it just
emphasizes some unfamiliarity with the C++ type system. Once you
start adding a type qualifier, you have to spell out clearly its
interaction with the type system (including overload resolution) and
separate compilation.
- no worries; yes I simply believe attempting to capture the necessary
subtleties of literal objects and references imply the necessity of
a distinct qualifier, although not necessary in the source language, as
literal objects are declared by context and syntax, not by explicitly
typed declaration.
| the problem, where if hypothetically 'literal' were a valid qualifier,
| then the problem would be easy to solve, and also flexibly enable the
that solve is only apparent. It introduces a whole can of worms you
seem to handwave.
- I admit some hand-waving, but would be pleased to try to be more
specific, if you could point out a more specific complexity which it
introduces? (as I've already tried to point out issues that it helps
resolve for which 'const' is not sufficiently differentiating.)
| definition of functions which accept and return references to literals,
| as being distinct from const, where const means simply not writeable
| presently, not necessary never (i.e. can't ever assign to references,
| which is what literal semantics would seem to dictate.):
But const in C++ does not mean no writeable. This is another
symptom of unfamiliarity with the C++ type system.
- I believe I understand that 'const' implies a set of semantics depending
on the context of the object's use; one of which relate to the ability to
modify it's value directly and/or indirectly dependant on the objects then
current contextual 'const' qualification. Which I attempt to differentiate
from literal objects, which have so such valid disqualification.
| #include stdio.h
|
| int main (void)
| {
|// non-const pointers to literals should at least warn,
|// and assignments to literals should generate an error.
|char *cp = (a); // compiles without warning/error (literal*)?
I have a warning on my system -- what are you using?
- sorry, actually complied using C on the most current tools for OSX 10.3.9.
| // ((char *)cp)[1] = 't';// compiles without warning/error - bus error!
because you shall not. The rule is quite simple : thou shalt not
modify a const object. No but, no if. Period.
- but does compile without error?
(because once assigned to a pointer GCC couldn't differentiate between
a 'const' reference which may be potentially validly cast away, and a
literal reference which may never be validly cast away?)
|printf(cp); // dies above if uncommented, otherwise (a)
|
|char ca[4] = (b); // compiles without warning/error.
|((char *)ca)[1] =
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-16 17:00 ---
Subject: Re: static_cast falsely allows const to be cast away
schlie at comcast dot net [EMAIL PROTECTED] writes:
| (In reply to comment #9)
| Subject: Re: static_cast falsely allows const to be cast away
|
| Gabriel Dos Reis writes:
| | --- Additional Comments From schlie at comcast dot net 2005-05-16
| | (In reply to comment #7)
| | Subject: Re: static_cast falsely allows const to be cast away
| | That is your view. However, not because GCC implements the ISO C++
| | view of types, means that GCC has a narrow view of a type is. I
| | suspect that part of your speculation is based on unfamiliarity with
| | both the C++ type system and the GCC internal notion of types.
| |
| | - but apparently inadequate to express the necessary differentiation
| | between constant and literal objects, as needed to be tracked by a
| | compiler for these languages?
|
| I don't think the distinction is necessary -- I can see arguments why
| people would want it, but it is not necessary. You're speaking of
| literals but seem to forget that 0 and 0+0 should be put in the
| same category though the latter is not a literal. So, literal is not
| the right thing. The notion used in C++ is constant expressions, that
| directly leads to const objects.
|
| - to me constant expression is an oxymoron,
then, you're out of luck.
[...]
| | definition of functions which accept and return references to literals,
| | as being distinct from const, where const means simply not writeable
| | presently, not necessary never (i.e. can't ever assign to references,
| | which is what literal semantics would seem to dictate.):
|
| But const in C++ does not mean no writeable. This is another
| symptom of unfamiliarity with the C++ type system.
|
| - I believe I understand that 'const' implies a set of semantics depending
| on the context of the object's use; one of which relate to the ability to
| modify it's value directly and/or indirectly dependant on the objects then
| current contextual 'const' qualification. Which I attempt to differentiate
| from literal objects, which have so such valid disqualification.
|
| | #include stdio.h
| |
| | int main (void)
| | {
| |// non-const pointers to literals should at least warn,
| |// and assignments to literals should generate an error.
| |char *cp = (a); // compiles without warning/error (literal*)?
|
| I have a warning on my system -- what are you using?
|
| - sorry, actually complied using C on the most current tools for OSX 10.3.9.
If you fill a PR about C++ while you're testing C, you do not expect
anything useful out it. Do you? Anyway, you do get a warning with
both C and C++ front-end if you say -Wwrite-strings.
[...]
| (or are you asserting that in C++ unlike C, 'const' objects are all literal
| values, who's values are never allocated and subsequently computed and/or
| modified at run-time, which doesn't seem to be purely the case?)
I'm claiming that
(1) const has a different semantics in C++ than in C.
(2) const objects cannot be modified in C++ -- if you do, you get
what you deserve.
(3) in C++, const objects initialized with constant expressions, can
participate in constant expressions. Consequently, if their
addresses are never taken, the compiler will not allocate
storage for them. G++ has been doing that optimization for ages
now. Notice that, that differs from C.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 14:36 --- Yup, string literal should have type 'const char *'. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 14:36:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-15 22:45 --- (In reply to comment #2) Yup, string literal should have type 'const char *'. I believe 'static const char []' would seem most correct? (where although 'static const' may be cast away, there's no guarantee that any attempted write will not only potentially fail, but may generate terminal exception if the string literal is stored in physically write protected memory or physically in ROM) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-15 22:50 --- (In reply to comment #1) With -Wwrite-strings, I do get a warning: t.cc:3: warning: deprecated conversion from string constant to �char*�' - arguably, this warning should always be on, and only optionally turned off when one want's to live dangeriously; it would seem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-16 00:14 --- Subject: Re: static_cast falsely allows const to be cast away schlie at comcast dot net [EMAIL PROTECTED] writes: | --- Additional Comments From schlie at comcast dot net 2005-05-15 22:45 --- | (In reply to comment #2) | Yup, string literal should have type 'const char *'. | | I believe 'static const char []' would seem most correct? static is not part of the type. The ty[e of a string literal is const char[N], N being its sizeof. There is no if no but. Similar rule for wide string literal. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-16 02:44 --- (In reply to comment #5) Subject: Re: static_cast falsely allows const to be cast away | Yup, string literal should have type 'const char *'. | | I believe 'static const char []' would seem most correct? static is not part of the type. The ty[e of a string literal is const char[N], N being its sizeof. There is no if no but. Similar rule for wide string literal. Then maybe GCC needs to broaden it's view of what information needs to be considered a type qualifier at least internally; as a storage specification can certainly restrict an object's permissible use and access, as such should be recorded and maintained as a qualifier for all objects, and pointers/references. A literal string is not simply a 'const char [N]' object, as a literal value may not be specified as a target of an assignment, directly or indirectly though a pointer cast to a non-const object reference, unlike as a plain old 'const' objects may be. Therefore possibly GCC needs to internally (and possibly optionally externally) introduce a 'literal' type qualifier, which is stronger than 'const', which may not be cast away, or be disregarded when a so qualified pointer is passed as an argument to, or returned from a function call. As although C/C++ languages don't define a 'literal' type/storage qualifier 'key-word', they certainly do specify restricted semantics for literal data use/access. Which today GCC tries to deal with by wrapping in constructors, and/or attempting to use some un-coordinated combination of 'const and/or TREE_READONLY object or reference attributes; where a 'literal' type qualifier would seem likely both simpler and more consistent overall? (where previously I had mistakenly equated static const == literal) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-16 02:54 --- Subject: Re: static_cast falsely allows const to be cast away schlie at comcast dot net [EMAIL PROTECTED] writes: | --- Additional Comments From schlie at comcast dot net 2005-05-16 02:44 --- | (In reply to comment #5) | Subject: Re: static_cast falsely allows const to be cast away | | Yup, string literal should have type 'const char *'. | | | | I believe 'static const char []' would seem most correct? | | static is not part of the type. The ty[e of a string literal is | const char[N], N being its sizeof. There is no if no but. | Similar rule for wide string literal. | | Then maybe GCC needs to broaden it's view of what information | needs to be considered a type qualifier at least internally; as a | storage specification can certainly restrict an object's permissible | use and access, as such should be recorded and maintained as a | qualifier for all objects, and pointers/references. That is your view. However, not because GCC implements the ISO C++ view of types, means that GCC has a narrow view of a type is. I suspect that part of your speculation is based on unfamiliarity with both the C++ type system and the GCC internal notion of types. | A literal string is not simply a 'const char [N]' object, as a | literal value may not be specified as a target of an assignment, | directly or indirectly though a pointer cast to a non-const object | reference, unlike as a plain old 'const' objects may be. But, a plain old 'const' object cannot be a target of an assignment. There is no different there -- and certainly static does not imply a difference there -- so the basis of your argument seems fragile to begin with. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-16 05:07
---
(In reply to comment #7)
Subject: Re: static_cast falsely allows const to be cast away
That is your view. However, not because GCC implements the ISO C++
view of types, means that GCC has a narrow view of a type is. I
suspect that part of your speculation is based on unfamiliarity with
both the C++ type system and the GCC internal notion of types.
- but apparently inadequate to express the necessary differentiation between
constant and literal objects, as needed to be tracked by a compiler for
these languages?
| A literal string is not simply a 'const char [N]' object, as a
| literal value may not be specified as a target of an assignment,
| directly or indirectly though a pointer cast to a non-const object
| reference, unlike as a plain old 'const' objects may be.
But, a plain old 'const' object cannot be a target of an assignment.
There is no different there -- and certainly static does not imply a
difference there -- so the basis of your argument seems fragile to
begin with.
- subtle possibly, but not fragile; the following simple program illustrates
the problem, where if hypothetically 'literal' were a valid qualifier,
then the problem would be easy to solve, and also flexibly enable the
definition of functions which accept and return references to literals,
as being distinct from const, where const means simply not writeable
presently, not necessary never (i.e. can't ever assign to references,
which is what literal semantics would seem to dictate.):
#include stdio.h
int main (void)
{
// non-const pointers to literals should at least warn,
// and assignments to literals should generate an error.
char *cp = (a); // compiles without warning/error (literal*)?
// ((char *)cp)[1] = 't';// compiles without warning/error - bus error!
printf(cp); // dies above if uncommented, otherwise (a)
char ca[4] = (b); // compiles without warning/error.
((char *)ca)[1] = 't';// compiles without warning/error.
printf(ca); // outputs (t), as expected.
// as above.
const char *ccp = (c); // compiles without warning/error (literal*)
// ((char *)ccp)[1] = 't'; // compiles without warning/error - bus error!
printf(ccp); // dies above if uncommented, otherwise (a)
const char cca[4] = (d);// compiles without warning/error.
((char *)cca)[1] = 't'; // compiles without warning/error.
printf(cca); // outputs (t), as expected.
// as above.
static const char sca[4] = (e); // compiles w/o warning/error (literal*)
// ((char *)sca)[1] = 't'; // compiles without warning/error, (bus error)!
printf(sca); // dies above if uncommented, otherwise (a)
// as above.
(f);// compiles without warning/error (literal*)
// ((char *)(f))[1] = 't'; // compiles without warning/error - bus error!
printf((f));// dies above if uncommented, otherwise (a)
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
-- What|Removed |Added Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 20:14 --- With -Wwrite-strings, I do get a warning: t.cc:3: warning: deprecated conversion from string constant to char*' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
