* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
@ 2005-03-14 20:13 ` pinskia at gcc dot gnu dot org
2005-03-14 20:14 ` pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-03-14 20:13 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
2005-03-14 20:13 ` [Bug c++/20475] " pinskia at gcc dot gnu dot org
@ 2005-03-14 20:14 ` pinskia at gcc dot gnu dot org
2005-05-15 14:37 ` lerdsuwa at gcc dot gnu dot org
` (9 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-03-14 20:14 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
2005-03-14 20:13 ` [Bug c++/20475] " pinskia at gcc dot gnu dot org
2005-03-14 20:14 ` pinskia at gcc dot gnu dot org
@ 2005-05-15 14:37 ` lerdsuwa at gcc dot gnu dot org
2005-05-15 22:45 ` schlie at comcast dot net
` (8 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: lerdsuwa at gcc dot gnu dot org @ 2005-05-15 14:37 UTC (permalink / raw)
To: gcc-bugs
------- 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|0000-00-00 00:00:00 |2005-05-15 14:36:54
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (2 preceding siblings ...)
2005-05-15 14:37 ` lerdsuwa at gcc dot gnu dot org
@ 2005-05-15 22:45 ` schlie at comcast dot net
2005-05-15 22:50 ` schlie at comcast dot net
` (7 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: schlie at comcast dot net @ 2005-05-15 22:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (3 preceding siblings ...)
2005-05-15 22:45 ` schlie at comcast dot net
@ 2005-05-15 22:50 ` schlie at comcast dot net
2005-05-16 0:15 ` gdr at integrable-solutions dot net
` (6 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: schlie at comcast dot net @ 2005-05-15 22:50 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (4 preceding siblings ...)
2005-05-15 22:50 ` schlie at comcast dot net
@ 2005-05-16 0:15 ` gdr at integrable-solutions dot net
2005-05-16 2:44 ` schlie at comcast dot net
` (5 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-16 0:15 UTC (permalink / raw)
To: gcc-bugs
------- 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" <gcc-bugzilla@gcc.gnu.org> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (5 preceding siblings ...)
2005-05-16 0:15 ` gdr at integrable-solutions dot net
@ 2005-05-16 2:44 ` schlie at comcast dot net
2005-05-16 2:54 ` gdr at integrable-solutions dot net
` (4 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: schlie at comcast dot net @ 2005-05-16 2:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (6 preceding siblings ...)
2005-05-16 2:44 ` schlie at comcast dot net
@ 2005-05-16 2:54 ` gdr at integrable-solutions dot net
2005-05-16 5:08 ` schlie at comcast dot net
` (3 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-16 2:54 UTC (permalink / raw)
To: gcc-bugs
------- 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" <gcc-bugzilla@gcc.gnu.org> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (7 preceding siblings ...)
2005-05-16 2:54 ` gdr at integrable-solutions dot net
@ 2005-05-16 5:08 ` schlie at comcast dot net
2005-05-16 9:07 ` gdr at integrable-solutions dot net
` (2 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: schlie at comcast dot net @ 2005-05-16 5:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (8 preceding siblings ...)
2005-05-16 5:08 ` schlie at comcast dot net
@ 2005-05-16 9:07 ` gdr at integrable-solutions dot net
2005-05-16 13:26 ` schlie at comcast dot net
2005-05-16 17:00 ` gdr at integrable-solutions dot net
11 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-16 9:07 UTC (permalink / raw)
To: gcc-bugs
------- 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" <gcc-bugzilla@gcc.gnu.org> 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 object"s.
| > | 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (9 preceding siblings ...)
2005-05-16 9:07 ` gdr at integrable-solutions dot net
@ 2005-05-16 13:26 ` schlie at comcast dot net
2005-05-16 17:00 ` gdr at integrable-solutions dot net
11 siblings, 0 replies; 14+ messages in thread
From: schlie at comcast dot net @ 2005-05-16 13:26 UTC (permalink / raw)
To: gcc-bugs
------- 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 object"s.
- 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 "otherwise"s 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] = 't'; // compiles without warning/error.
>| printf(ca); // outputs "(t)", as expected.
>
> because of initialization of the array.
- yes, as expected; but would further expect a warning/error for:
const char *ccp = "(c)";// which is fine.
((char *)ccp)[1] = 't'; // unless one attempts to cast away a reference
// to a literal, as opposed to a 'const' variable.
(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?)
-paul-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/20475] static_cast falsely allows const to be cast away
2005-03-14 19:02 [Bug c++/20475] New: static_cast falsely allows const to be cast away dcb314 at hotmail dot com
` (10 preceding siblings ...)
2005-05-16 13:26 ` schlie at comcast dot net
@ 2005-05-16 17:00 ` gdr at integrable-solutions dot net
11 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-16 17:00 UTC (permalink / raw)
To: gcc-bugs
------- 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" <gcc-bugzilla@gcc.gnu.org> 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 object"s.
|
| - 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
^ permalink raw reply [flat|nested] 14+ messages in thread