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

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

[dcb314 at hotmail dot com]

I just tried the following block of C++ code with g++ 20050311, the
latest snapshot.

void f()
{
        char * pj2 = static_cast < char * > ("fred");
}

The compiler said

dcb@linux:~/C++/src> ~/gnu/20050311/results/bin/g++ -c sc.cc

I added more flags

dcb@linux:~/C++/src> ~/gnu/20050311/results/bin/g++ -g -O2 -Wall -ansi -pedantic
-c sc.cc
sc.cc: In function `void f()':
sc.cc:5: warning: unused variable 'pj2'
dcb@linux:~/C++/src>

However, my reading of Stroustrup 3, page 414, section 15.4.2.1 says that
static_cast can't be used to cast away const.

I think the compiler should complain about the above code. Here is Intel C++ 8.1
doing what I want.

sc.cc(5): error: static_cast cannot cast away const or other type qualifiers
        char * pj2 = static_cast < char * > ("fred");
                     ^

This example derived from real code in Suse Linux 9.2

-- 
           Summary: static_cast falsely allows const to be cast away
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dcb314 at hotmail dot com
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475

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

[pinskia at gcc dot gnu dot org]

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

[pinskia at gcc dot gnu dot org]

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

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

[lerdsuwa at gcc dot gnu dot org]

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

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

[schlie at comcast dot net]

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

[schlie at comcast dot net]

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

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

[gdr at integrable-solutions dot net]

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

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

[schlie at comcast dot net]

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

[gdr at integrable-solutions dot net]

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

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

[schlie at comcast dot net]

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

[gdr at integrable-solutions dot net]

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

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

[schlie at comcast dot net]

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

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

[gdr at integrable-solutions dot net]

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

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

[manu at gcc dot gnu dot org]

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