On 12/11/15 12:33, Clemens Ladisch wrote:
Marcus Shawcroft wrote:
On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com>
wrote:
* The first one can be solved. The space in the call of CONCAT2(a,
b) by
CONCAT() is propagated into the subsequent calls. It means when the
strings
'a' and 'b' are concatenated, the space is inserted between both
strings -
which is not the expected behaviour.
The fix would be:
-#define CONCAT(a, b) CONCAT2(a, b)
+#define CONCAT(a, b) CONCAT2(a,b)
Have you looked at the C standard on this issue? I wonder which
compiler, gcc or clang is not compliant with the standard.
6.10.3.3:
| If, in the replacement list of a function-like macro, a parameter is
| immediately preceded or followed by a ## preprocessing token, the
| parameter is replaced by the corresponding argumentâs preprocessing
| token sequence; [â]
| each instance of a ## preprocessing token in the replacement list
| (not from an argument) is deleted and the preceding preprocessing
| token is concatenated with the following preprocessing token.
Preprocessing tokens are defined in 6.4:
| preprocessing-token:
| header-name
| identifier
| pp-number
| character-constant
| string-literal
| punctuator
| each non-white-space character that cannot be one of the above
| [â]
| White space may appear within a preprocessing token only as part of
| a header name or between the quotation characters in a character
| constant or string literal.
So clang is wrong.
It should be noted that example 4 (6.10.3.5 6) shows such a space:
#define glue(a, b) a ## b
#define xglue(a, b) glue(a, b)
I looked at this with a colleague who had clang installed on his
machine. It looks as though this problem may only occur when
pre-processing assembly language files. If so, that's somewhat
unfortunate.
However, I'm not against taking a patch that's as trivial as this; it
doesn't harm how GCC handles this file. It should however, be
accompanied by a comment explaining that it's for compatibility with
LLVM.
R.
Regards,
Clemens