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

["schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>]

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