[Bug c++/20475] static_cast falsely allows const to be cast away

["gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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