Compiling GCC With a C++ Compiler (g++)

[Matt Austern]

On Oct 13, 2004, at 3:09 AM, Andreas Schwab wrote:

> "Dave Korn" <dk@artimi.com> writes:
>
>>> -----Original Message-----
>>> From: gcc-owner On Behalf Of Gabriel Dos Reis
>>> Sent: 13 October 2004 04:47
>>
>>> Phil Edwards writes:
>>>
>>> [...]
>>>
>>> | particular place.  Since member init-lists aren't available
>>> for STRING_CST,
>>> | we have to cast away the const in build_string
>>>
>>> which is undefined behaviour by C rules  (and C++ too).
>>
>>   I'll bet alias analysis just loves it too.  Wouldn't using tricks 
>> like
>> this lead to a situation in the future (if and) when there's full IPA 
>> in gcc
>> and it can't bootstrap itself reliably any more?
>
> In C you are always allowed to cast away const and write through the
> resulting lvalue as long as the underlying object is not read-only.

I think this discussion is probably best conducted using precisely the 
wording in the C standard.  I don't believe the phrase "read-only" is 
defined in that standard.  Here's my analysis.

Clause 6.7.3/5 says "If an attempt is made to modify an object defined 
with a const-qualified type through use of an lvalue with 
non-const-qualified type, the behavior is undefined."

Clause 6.2.5/25 says what a const-qualified type is: "Each unqualified 
type has several qualified versions of its type, corresponding to the 
combinations of one, two, or all three of the const, volatile, and 
restrict qualifiers."

In this case we're dealing with a structure one of whose fields has a 
const-qualified type.  So the only remaining question is whether a 
single field can be an object.  The answer is yes: clause 3.14 defines 
object, and the definition is very general: a "region of data storage 
in the execution environment, the contents of which can represent 
values."

So I believe that this is undefined behavior in C.  We can probably get 
away with it, but it would also probably be better to find a way of 
doing this that doesn't invoke undefined behavior.

			--Matt