This is the mail archive of the 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: [tree-ssa] Merge status

In message <>, "Josep
h S. Myers" writes:
 >On Sun, 14 Mar 2004, Ian Lance Taylor wrote:
 >> I agree.  It is very easy to write casts as lvalues, and for a long
 >> time gcc didn't even warn about them.  In looking through the mail
 >> archives, I see cogent reasons for removing the extension for C++, but
 >> no good reasons to remove it for C.  As far as I know, the extension
 >> is umabiguous in C, and is simply syntactic sugar.
 >Syntactic sugar and, therefore, not worth the costs in maintainability;
 >extensions should add expressive value to justify themselves.  See the
 >amount of code removed that was to support extended lvalues as evidence.  
 >(There were also cases where -pedantic caused errors rather than warnings
 >from extended lvalues, which did not seem worthwhile to fix - this does
 >mean the deprecation warnings in 3.4 may not trigger for the case where
 >the cast is to the same type.)
 >One of the biggest users of GCC extensions is the Linux kernel; Linus
 >Torvalds has supported getting rid of this extension, describing it as
 >"braindamaged". I concur; code using the extension seems to be
 >intrinsically obfuscated.
 >If SPEC uses extended lvalues, how did it ever work with non-GCC
cast-as-lvalue is used all over the place.  It's unfortunately become
quite pervasive in C code.  Somewhere around 10% of all the packages
found in Fedora use the cast-as-lvalue extension in one way or another.

Removing cast-as-lvalue in some cases merely exchanges reasonably clean
code for hideous code.  Look at /usr/include/rpc/xdr.h for example.


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