This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C constant expressions proposals


"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> On Sat, 14 Aug 2004, Zack Weinberg wrote:
>
>> I also don't think this category of bugs ("fine details of what is or
>> is not valid C") is worth spending much time or effort on, compared to
>> the giant pile of wrong-code-generation, ICE, and poor-optimization
>> bugs that are out there.
>
> That sort of argument is why the proposal (or rather the introductory text 
> around it) specifically lists other benefits in terms of cleaning up 
> misuses of trees (in advance of constant expressions implementation) and 
> getting rid of NON_LVALUE_EXPR (afterwards).  (This or that feature has a 
> kludged use to do some bit of constant expressions, so to get rid of that 
> feature without regressions a better implementation is needed first, after 
> which that feature can be got rid of.)

Ah.  That makes this a lot more worth doing in my book, but I still
don't care very much about what the precise semantics of constant
expressions turn out to be.

>> Since you specifically ask about 20010327-1.c, I think it looks
>> awfully like the sort of code that people write down in the guts of an
>> operating system, and I think we have broken those people's code a lot
>> and maybe we should think about cutting them some slack.
>
> It's only the version with a cast to an integer of different width that's 
> a problem (and specifically when longs are a different width from 
> pointers).  The case of a cast to an integer of the same width is 
> 20011114-1.c, which I propose to keep valid.

Ok, then I don't have a problem with breaking 20010327-1.c.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]