From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16863 invoked from network); 13 May 2020 20:31:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 20:31:49 -0000 Received: (qmail 18270 invoked by uid 550); 13 May 2020 20:31:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18252 invoked from network); 13 May 2020 20:31:46 -0000 X-Virus-Scanned: Debian amavisd-new at nospam.ludd.ltu.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ludd.ltu.se; s=mail; t=1589401892; bh=p4EC2VOJyGuQzC6oPRqWFqA9IoSUbGmSz7PQYnDscmo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mRRZsDNb3qmCDSE33VpdNV3LphwWaevGYyouWS+D2QpY4n7FPi+WAMdb7bt+rWSvH 9RxGhjitAu1gRmuxgFIxlUcoPYiw4Ciwl9k7WdGmDrq59aXLtsL5RJyWIDrQraueUk yqd3gIKuE92ntnWy5fu10aZiMmVsItDAGo2+8KEg= To: Rich Felker Cc: John Arnold , musl@lists.openwall.com, pcc@lists.ludd.ltu.se References: <20200512212127.GQ21576@brightrain.aerifal.cx> <5ae8c7fa-aed9-d957-fe53-68eb2fa622a6@ludd.ltu.se> <20200513143033.GU21576@brightrain.aerifal.cx> <9b35636f-0af4-09fc-a7c5-53814a416e24@ludd.ltu.se> <20200513193353.GA21576@brightrain.aerifal.cx> From: Anders Magnusson Message-ID: <698e1de6-2e35-0516-5637-6fb8f8273ce3@ludd.ltu.se> Date: Wed, 13 May 2020 22:31:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200513193353.GA21576@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Subject: Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier) Den 2020-05-13 kl. 21:33, skrev Rich Felker: > On Wed, May 13, 2020 at 09:09:13PM +0200, Anders Magnusson wrote: >> Den 2020-05-13 kl. 16:30, skrev Rich Felker: >>> On Wed, May 13, 2020 at 09:10:40AM +0200, Anders Magnusson wrote: >>>> Den 2020-05-12 kl. 23:21, skrev Rich Felker: >>>>> Thanks. Adding pcc list to cc. >>>>> >>>>> On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote: >>>>>> With an i386 PCC 1.2.0.DEVEL built from source from >>>>>> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to >>>>>> build an i386 musl 1.2.0. The compiler first hits this error: >>>>>> >>>>>> ../include/limits.h:10: error: bad charcon >>>>>> >>>>>> This line was the only change made in commit cdbbcfb8f5d, but it has a >>>>>> lengthy commit message about the proper way of determining CHAR_MIN >>>>>> and CHAR_MAX. >>>>> I think this is clearly a PCC bug, one they can hopefully fix. The >>>>> commit message cites the example from 6.4.4.4: >>>> Can you please sen med the offending line? >>> #if '\xff' > 0 >>> >> Thanks, fixed now, it was a missing pushback of ' that was the problem. >> >> Note that this check cannot be used to see whether a target uses >> signed or unsigned char. >> In pcc the above is always true, no matter what char is.  See C11 >> clause 6.10.1 clause 4. > See the commit message for: > > https://git.musl-libc.org/cgit/musl/commit/include/limits.h?id=cdbbcfb8f5d748f17694a5cc404af4b9381ff95f > > There is good reason we changed this. > > I believe you're referring to the text: > > "This includes interpreting character constants, which may involve > converting escape sequences into execution character set members. > Whether the numeric value for these character constants matches > the value obtained when an identical character constant occurs in > an expression (other than within a #if or #elif directive) is > implementation-defined.168) Also, whether a single-character > character constant may have a negative value is > implementation-defined." > Actually, the ambiguous handling of negative values in #if is historical behaviour, and has nothing to do with EBCDIC. It do not sound very good to rely on explicitly documented undefined behaviour IMHO, and this is actually the first time in the last 20 years that someone has complained about it :-) It might be possible to change it (due to the "law of least surprise") but since cpp do not have any relation to the target architecture it needs some thinking. (cpp is the same even if multiple target backends are generated). -- Ragge