[cfe-commits] [Patch] Fix for comma-removal ahead of __VA_ARGS__ in macros

[Andy Gibbs]

On Monday, November 05, 2012 9:50 AM, Jean-Daniel Dupas wrote:
> Le 5 nov. 2012 à 09:08, Eli Friedman a écrit :
>> On Sun, Nov 4, 2012 at 3:10 PM, Andy Gibbs wrote:
>>> Hi,
>>>
>>> Please could someone review the attached patch for me before I commit 
>>> it.
>>>
>>> This patch fixes the rules surrounding the removal of a leading comma 
>>> where
>>> a __VA_ARGS__ expansion is empty.
>>>
>>> GCC has the extension, implemented already in clang for...
>>>
>>> #define M(...) call(a, ## __VA_ARGS__)
>>>
>>> This will expand to "call(a)" for "M()", removing the comma.  However, 
>>> under
>>> -std=c99, this behaviour changes so that the comma is not removed. The
>>> attached patch follows this behaviour when in c99 mode in clang.  In 
>>> gnu99
>>> mode, it behaves as before, and similarly for pre-c99 dialects and for 
>>> c++
>>> (all checked against gcc's behaviour).
>>
>> Why do we need to change the behavior in C99 mode?  As far as I can
>> tell, it's impossible to construct a strictly conforming program for
>> which the C99 standard specifies behavior different from the gcc
>> extension.
>
> It's going to break a lot of code. clang defaults to C99 (as does Xcode
> projects) and a lot of code rely on this behavior.

Actually, clang defaults to C99 with GNU extensions turned on (i.e.
-std=gnu99), not to strict C99 mode.  So unless -std=c99 is explicity
set, this will not affect existing code.

Of course, code broken by this change would also be broken by compiling with
gcc instead...

Here is the line from the gcc help: "... In this case the C99 standard is
clear that the comma must remain, however the existing GCC extension used to
swallow the comma. So CPP retains the comma when conforming to a specific C
standard, and drops it otherwise."

IMHO, clang is at variance to gcc's own extension.  Of course, if the wish
of the clang developers is to make this divergence, I personally have no
issue with that, although it should probably be documented somewhere that
clang doesn't strictly follow gcc in all modes.  I, on my side, was made
aware of this divergence when presented with code which compiled differently
on clang compared with gcc, and this was found to be the cause.

Should I just commit the change relating to Microsoft mode for now?  The
PR on this can then be closed out.  This part should have no impact on code
compiled with -std=c99.

Cheers
Andy