Request to drop daft GNU extension

Request to drop daft GNU extension

[Neil Booth]

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.

The one I'd like to drop is the following kludged meaning of ##
(taking the example from the info manual)

#define eprintf(format, args...) fprintf (stderr, format , ## args)

My reasons for doing so are as follows:

1) This use of ## has nothing to do with its true meaning of token
   pasting, certainly when our macro expanding is token-based.
   See point 4) for an example of why this is a problem.

2) It is entirely redundant.  The justification put forth in the manual
   is resolving the "embarrassment" of an extra comma when invoked as

   eprintf ("success!\n", )

   which gives

   fprintf (stderr, "success!\n", )

   However, this is just masking the fact that your macro really has
   more arguments in the variable part than you're claiming it has,
   and thus I would suggest that it should be redefined as:-

   #define eprintf(format...) fprintf (stderr, format)

   and then the invocations

   eprintf ("%s:%d: ", input_file_name, line_number)
   eprintf ("success!\n")

   give the desired result in both cases.  This redundancy is what
   convinces me there will never be anything like this in the standard.

3) It prevents correct usage of ##.  Consider

   #define foo(a, b...) a ## b

   Invoking this macro with

   foo (1, )

   drops the 1 to give an empty expansion, whereas it should expand as
   the single token <1>.

4) It makes the macro expansion code uglier than it already is.


I have implemented it in the new macro expander, but I don't think we
should implement it.  Comments?

Neil.

Re: Request to drop daft GNU extension

[Neil Booth]

Neil Booth wrote:-

Oops.

>    See point 4) for an example of why this is a problem.
         ^^^^^^^point 3

Neil.

Re: Request to drop daft GNU extension

[Andi Kleen]

Neil Booth <NeilB@earthling.net> writes:
> 
> I have implemented it in the new macro expander, but I don't think we
> should implement it.  Comments?

You would break lots of code -- it is actually used.

-Andi

Re: Request to drop daft GNU extension

[Neil Booth]

Andi Kleen wrote:-

> You would break lots of code -- it is actually used.
> 

I realise that, but my point is that its use is unnecessary.

Neil.

Re: Request to drop daft GNU extension

[David Edelsohn]

	It's use may be unnecessary, but getting all of the old code
corrected is difficult, especially if the code is useful yet no longer
maintained. 

	Is it possible to have this as a switch which initially accepts
the code and warns, so that in the next release after the one with the
warning we can turn it off by default yet allow people to compile the old
code if they must?

David

Re: Request to drop daft GNU extension

[Neil Booth]

David Edelsohn wrote:-

> 	Is it possible to have this as a switch which initially accepts
> the code and warns, so that in the next release after the one with the
> warning we can turn it off by default yet allow people to compile the old
> code if they must?

This is my inclination.  Does anyone object to this?  For the moment,
we just issue a warning at the location of the definition and each use
of the ## token-deleting "feature"?

Neil.

Re: Request to drop daft GNU extension

[Zack Weinberg]

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

Re: Request to drop daft GNU extension

[Martin v. Loewis]

> 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 in favour of dropping it, but I would really like to see the C99
version as a replacement, not an ongoing support for the GNU macro
varargs feature. If possible, the preprocessor should detect that a
certain expansion has a different meaning under GNU C and C99, issue a
warning, and use the C99 meaning. There should be an option to restore
the GNU C meaning.

> #define eprintf(format, args...) fprintf (stderr, format , ## args)

In C99, this would be written as

#define eprintf(format, ...) fprintf (stderr, format __VA_ARGS__)

Right?

Regards,
Martin

Re: Request to drop daft GNU extension

[Neil Booth]

Martin v. Loewis wrote:-

> I'm in favour of dropping it, but I would really like to see the C99
> version as a replacement, not an ongoing support for the GNU macro
> varargs feature. If possible, the preprocessor should detect that a
> certain expansion has a different meaning under GNU C and C99, issue a
> warning, and use the C99 meaning. There should be an option to restore
> the GNU C meaning.

That's ongoing support, though, no?  Or do you mean with the intent of
dropping it altogether in some later version?

> 
> > #define eprintf(format, args...) fprintf (stderr, format , ## args)
> 
> In C99, this would be written as
> 
> #define eprintf(format, ...) fprintf (stderr, format __VA_ARGS__)
> 
> Right?

Yes, if you're happy writing something like

eprintf ("string", )

for the empty case.  Alternatively

#define eprintf(...) fprintf (stderr, __VA_ARGS__)

doesn't require that extra comma in the invocation.  But then

eprintf()

is not a cpp error, and you'd have to wait for the front end to issue
an error.

Neil.