Building newlib for Cortex-M with LLVM
Thu Nov 12 12:39:00 GMT 2015
Marcus Shawcroft wrote:
> On 11 November 2015 at 23:16, Olivier MARTIN <firstname.lastname@example.org> 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.
| 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:
| 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 (18.104.22.168 6) shows such a space:
#define glue(a, b) a ## b
#define xglue(a, b) glue(a, b)
More information about the Newlib