This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Request to drop daft GNU extension
- To: Neil Booth <NeilB at earthling dot net>
- Subject: Re: Request to drop daft GNU extension
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Sat, 10 Jun 2000 20:03:55 -0700
- Cc: gcc at gcc dot gnu dot org
- References: <E130udJ-00064L-00@monkey.rosenet.ne.jp>
On Sun, Jun 11, 2000 at 08:25:41AM +0900, Neil Booth wrote:
> I'd like to request we drop a GNU extension. I realise this will make
> me unpopular with the backwards compatibility crowd, but there are
> sound reasons for doing so.
I'm seriously ambivalent. This feature has been supported for a
decade and a half, and it's widely used. Most of the problems would
go away if we changed it to delete the previous token instead of the
previous nonwhitespace sequence (as we can now do, and as the manual
has threatened to do since 1989 or possibly earlier).
I do think there are things you can do with this feature and not
otherwise. Consider
#define error_in_bold(msgid, ap...) \
fprintf(stderr, "\e[1m" msgid "\e[0m\n" ,##ap)
Yes, that's got portability problems oozing out its ears, but it is
exactly the sort of code that someone might've written with this
extension. And they'll probably be infuriated if we break it.
However, C99 added varargs macros but did not include this feature.
From discussion on comp.std.c I would say it has no chance of being
incorporated into a future C standard. This sequence
#define prefix(...) do_ ## __VA_ARGS__
prefix(a, b, c, d)
prefix()
must come out as
do_a, b, c, d
do_
That means there's a serious inconsistency between anonymous (C99-ish)
varargs macros and our varargs macros - prefix() would expand to
nothing if it had been defined using named varargs.
On the whole, I'm willing to drop it at least in C99-compliant mode.
But I'd like to see some discussion of a replacement.
zw