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.3 required=5.0 tests=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 25037 invoked from network); 13 May 2020 21:49:48 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 21:49:48 -0000 Received: (qmail 18329 invoked by uid 550); 13 May 2020 21:49:45 -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 18308 invoked from network); 13 May 2020 21:49:44 -0000 Date: Wed, 13 May 2020 17:49:32 -0400 From: Rich Felker To: Anders Magnusson Cc: John Arnold , musl@lists.openwall.com, pcc@lists.ludd.ltu.se Message-ID: <20200513214931.GB21576@brightrain.aerifal.cx> 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> <698e1de6-2e35-0516-5637-6fb8f8273ce3@ludd.ltu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <698e1de6-2e35-0516-5637-6fb8f8273ce3@ludd.ltu.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier) On Wed, May 13, 2020 at 10:31:31PM +0200, Anders Magnusson wrote: > > > 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. I mean the 'z'-'a' differing between #if and if() is an EBCDIC artifact. Indeed the sign thing is more likely motivated by differing historical behaviors in a subtle corner case than by mixed charset environments. > It do not sound very good to rely on explicitly documented undefined > behaviour IMHO, It's not undefined. It's implementation-defined, and generally implementation-defined means roughly psABI-defined, or in other words "should match for all interoperable implementations". One way of thinking about this as an "ABI" issue is that 2 object files compiled by different compilers, with foo.h containing: #if 'z'-a'==25 #define func func1 #else #define func func2 #endif and one defining func and the other calling func, should successfully link if the compilers are interoperable. > 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). I'm pretty sure this is subtly wrong then because the signedness of wchar_t varies by target, and while the *values* may be allowed to vary, whether L'\0' has preprocessor type uintmax_t or intmax_t has to match whether wchar_t is unsigned or signed. Rich