From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118079 invoked by alias); 12 Nov 2015 12:33:29 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 117741 invoked by uid 89); 12 Nov 2015 12:33:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: dehamd003.servertools24.de Received: from dehamd003.servertools24.de (HELO dehamd003.servertools24.de) (31.47.254.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 12 Nov 2015 12:33:23 +0000 Received: from [10.1.2.65] (unknown [94.101.37.4]) by dehamd003.servertools24.de (Postfix) with ESMTPSA id C632FF520007; Thu, 12 Nov 2015 13:33:18 +0100 (CET) Subject: Re: Building newlib for Cortex-M with LLVM To: Marcus Shawcroft , Olivier MARTIN References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> Cc: Newlib Mailing List From: Clemens Ladisch Message-ID: <5644870C.6040106@ladisch.de> Date: Thu, 12 Nov 2015 12:39:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20151112123318.55555.39145@dehamd003.servertools24.de> X-PPP-Vhost: ladisch.de X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00798.txt.bz2 Marcus Shawcroft wrote: > On 11 November 2015 at 23:16, Olivier MARTIN 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