Re: [tree-ssa] Merge status

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Tue, 16 Mar 2004 law@redhat.com wrote:

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

I thought that free software was generally designed to be portable, not
just to systems with GCC, and that glibc and the Linux kernel were
exceptions to the norm of portability; certainly GNU software tries to be
portable.  (And Linux has rapidly been fixed, given Linus's opinion of
this extension as "braindamaged".)

(I suppose copying in the current version of obstack from gnulib, or in
similar cases disabling __GNUC__ conditionals to switch to the portable
non-GCC alternative, may be needed in some cases.)

(I also have the impression from past discussions on the GCC lists that
the new C++ parser in 3.4 breaks almost all C++ software by being stricter
without any deprecation period at all.)

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

So how were these casts-as-lvalues originally implemented by Sun for
non-GCC platforms?  Surely not using __extension__ and GNU extensions.

Perhaps the fixinclude for obstack.h needs to be generalised to cover
other headers.  The 3.4 manual defines what a cast-as-lvalue means, so
replacing with the expansion there (using __typeof__, in general, if the
type of a macro parameter isn't specified) should suffice.  I certainly
hope these macros aren't specified to allow arguments with side effects.

-- 
Joseph S. Myers
jsm@polyomino.org.uk