Re: Building newlib for Cortex-M with LLVM

[Clemens Ladisch <clemens@ladisch.de>]

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)


Regards,
Clemens