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: Patch to deprecate casts as lvalues for C

"Joseph S. Myers" <> writes:

> This patch deprecates the cast-as-lvalue extension for C (and so for
> Objective-C), as previously discussed.  (The deprecation warning
> doesn't cover the case of a cast to the same type, where -pedantic
> presently gives a hard error rather than a warning; I don't think it's
> worth making the deprecation warning cover this case for a feature
> that will be removed.)  The patch to gcc-3.4/changes.html is at the
> bottom.
> Bootstrapped with no regressions on i686-pc-linux-gnu.  OK to commit
> (the obstack.h patch (required for bootstrap with this patch, as
> obstack.h uses this unfortunate extension), and the libobjc patch)?
> (codingconventions.html is silent on any upstream nature of obstack,
> but the comments in obstack.c imply that the version used here is
> forked from the glibc one.)

The libobjc patch is OK.  The documentation patch can also go in now.

Since this deprecation affects all users of obstacks, you must
coordinate the change to obstack.h with the upstream (which I believe
is glibc) and you must also write a fixincludes edit so that systems
that shipped an old version of obstack.h in /usr/include are not
broken.  And you should see if there is a way of announcing this
across the entire GNU Project, because there are a lot of GNU packages
that ship obstack.[ch].  It's not just a libiberty thing.

You have to get obstack.h sorted out with upstream before you can
check in the changes to c-typeck.c.


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