--- Begin Message ---
- To: jk@espy.org
- Cc: doko@cs.tu-berlin.de, gcc@packages.debian.org
- Subject: Re: Empty struct initializer fix
- From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
- Date: Fri, 25 Feb 2000 08:34:23 +0100
- Message-id: <200002250734.IAA00745@loewis.home.cs.tu-berlin.de>
- In-reply-to: <v0422080eb4d9ba7efbc9@[206.163.71.146]> (message from Joel Klecker on Thu, 24 Feb 2000 19:44:41 -0800)
- References: <v04220806b4d7d6ee5e89@[206.163.71.146]> <14515.61649.43060.39844@bolero> <v0422080eb4d9ba7efbc9@[206.163.71.146]>
> Regarding #54951, I think we need upstream's comments on whether or
> not the __extension__ keyword should silence this particular
> warning, glibc upstream thinks it should.
I think it should, and it appears to be fixed in the mainline. Without
any deeper analysis, I'd say the patch
Wed Sep 22 06:25:15 1999 Jim Kingdon <http://developer.redhat.com>
* c-parse.in: save and restore warn_pointer_arith on __extension__
along with pedantic.
(SAVE_WARN_FLAGS, RESTORE_WARN_FLAGS): Added.
Set the type of extension to itype rather than $<itype>1 kludge.
* extend.texi (Alternate Keywords): Adjust documentation.
* c-parse.c, c-parse.y, objc-parse.c, objc-parse.y: Rebuilt.
fixed it.
> I have no clue on #57294.
It seems to be caused by a recursive definition of the strpbrk macro.
It roughly looks like
# define strpbrk(s, accept)
__extension__
({ char __a0, __a1, __a2;
<condition> ? <expression>
: strpbrk (s, accept); })
Under ANSI rules, strpbrk is not expanded recursively, under K&R
rules, it is.
Regards,
Martin
--- End Message ---