[Bug preprocessor/35010] New: preprocessor loses leading whitespace

[Bug preprocessor/35010] New: preprocessor loses leading whitespace

[sabre at nondot dot org]

This testcase:

#define debug(format, ...) format, ## __VA_ARGS__)
debug(X);
debug(Y, 1, 2);
debug(Y, 1, 2 );
debug(Z, );
debug(W,);

Should preprocess to:

X);
Y, 1, 2);
Y, 1, 2);
Z, );
W, );

not:

X);
Y, 1, 2);
Y, 1, 2);
Z,);
W,);


Z/W should have spaces.


-- 
           Summary: preprocessor loses leading whitespace
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sabre at nondot dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010

[Bug preprocessor/35010] preprocessor loses leading whitespace

[neil at gcc dot gnu dot org]

------- Comment #1 from neil at gcc dot gnu dot org  2008-05-15 02:54 -------
Chris - unless I'm missing something I disagree.  The 

, ## __VA_ARGS__

token sequence is being eaten in its entirety by the empty argument.  Then
between "format" and the ')' on the #define line, which is the ')' that appears
on the output, there is no whitespace.  It seems GCC's output is correct to me.


-- 

neil at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neil at gcc dot gnu dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010

[Bug preprocessor/35010] preprocessor loses leading whitespace

[neil at gcc dot gnu dot org]

------- Comment #2 from neil at gcc dot gnu dot org  2008-05-15 02:56 -------
Never mind, I see your point.  The comma isn't being eaten, right.


-- 

neil at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-15 02:56:17
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010

[Bug preprocessor/35010] preprocessor loses leading whitespace

[b07584 at freescale dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]



------- Comment #3 from b07584 at freescale dot com  2009-04-08 17:46 -------
(In reply to comment #0)
> This testcase:
> 
> #define debug(format, ...) format, ## __VA_ARGS__)
> debug(X);
> debug(Y, 1, 2);
> debug(Y, 1, 2 );
> debug(Z, );
> debug(W,);
> 
> Should preprocess to:
> 
> X);
> Y, 1, 2);
> Y, 1, 2);
> Z, );
> W, );
> 
> not:
> 
> X);
> Y, 1, 2);
> Y, 1, 2);
> Z,);
> W,);
> 
> 
> Z/W should have spaces.
> 
 Chris, I want to make sure I understand what you are saying. With:

#define debug(format, ...) format, ## __VA_ARGS__)

 For the the invocation:

debug(X);

 - the argument is omitted and hence the comma preceeding ## in the body is
 removed in accordance with GNU CPP's extended semantics, yielding:

X);

 In contrast, for the invocations:

debug(Z, );
debug(W,);

 when you say, the output ought to be:

Z, );
W, );

 - is it because a space preceeds the ## in the macro definition (i.e. body)?

 So, if the definition were to be:

#define debug(format, ...) format,## __VA_ARGS__)

 instead, then:

debug(Z, );
debug(W,);

 preprocessing to:

Z,);
W,);

 would be OK? This reasoning about the appearance (or non-appearance) of space
 is similar to Neil's explanation in the Cpplib Internals manual (for GCC
 version 4.4.0) in the section Token Spacing:

#define add(x, y, z) x + y +z

sum = add (1,2, 3)

 preprocesses to:

sum = 1 + 2 +3

 However in the case at hand, per ISO/IEC 9899:TC2 Committee Draft — May 6,
 2005 WG14/N1124, 6.10.3.3 "The ## operator", constraint 2: "... however, if an
 argument consists of no preprocessing tokens, the parameter is replaced by a
 placemarker preprocessing token instead." Further, in constraint 3:
 "... concatenation of a placemarker with a non-placemarker preprocessing token
 results in the non-placemarker preprocessing token."

 By that, the expansion sequence for (say):

debug(Z, );

 (with the first definition - i.e. the one with a space before the ##) would
be:

debug(Z, );

->

format, ## __VA_ARGS__)

(CPP_COMMA gets the PASTE_LEFT flag set, and <placemarker> is only conceptually
depicted per constraint 2)

->

CPP_NAME CPP_COMMA[PASTE_LEFT] <placemarker> CPP_CLOSE_PAREN CPP_SEMICOLON

(per constraint 3, CPP_COMMA and <placemarker> concatenate to CPP_COMMA)

->

CPP_NAME CPP_COMMA CPP_CLOSE_PAREN CPP_SEMICOLON

 So, the space before the ## does not make it to the expansion because this is
 the paste operation in operation - as it proceeds normally.

 Or perhaps, I am missing something? Kindly explain. Thanks.


-- 

b07584 at freescale dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b07584 at freescale dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010

[Bug preprocessor/35010] preprocessor loses leading whitespace

[sabre at nondot dot org]

------- Comment #4 from sabre at nondot dot org  2009-04-27 01:31 -------
If the definition is:
#define debug(format, ...) format,## __VA_ARGS__)
Then we should still get:
Z, );
W, );

If the definition is:
#define debug(format,...) format,##__VA_ARGS__)
Then we should get:
Z,);
W,);

(and gcc currently gets this right)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010

[Bug preprocessor/35010] preprocessor loses leading whitespace

[sabre at nondot dot org]

------- Comment #5 from sabre at nondot dot org  2009-04-27 01:31 -------
Sorry I can't give a more detailed analysis of what is going on, I have no idea
how the placemarker system works in gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35010