mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Anders Magnusson <ragge@ludd.ltu.se>
To: Rich Felker <dalias@aerifal.cx>
Cc: John Arnold <iohannes.eduardus.arnold@gmail.com>,
	musl@lists.openwall.com, pcc@lists.ludd.ltu.se
Subject: Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
Date: Wed, 13 May 2020 22:31:31 +0200	[thread overview]
Message-ID: <698e1de6-2e35-0516-5637-6fb8f8273ce3@ludd.ltu.se> (raw)
In-Reply-To: <20200513193353.GA21576@brightrain.aerifal.cx>



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

  reply	other threads:[~2020-05-13 20:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12 20:59 John Arnold
2020-05-12 21:21 ` Rich Felker
2020-05-13  7:10   ` [musl] Re: [Pcc] " Anders Magnusson
2020-05-13 14:30     ` Rich Felker
2020-05-13 19:09       ` Anders Magnusson
2020-05-13 19:33         ` Rich Felker
2020-05-13 20:31           ` Anders Magnusson [this message]
2020-05-13 21:49             ` Rich Felker
2020-05-13 17:00     ` John Arnold
2020-05-13 17:27       ` Rich Felker
2020-05-13 17:53         ` John Arnold
2020-05-13 18:04           ` Rich Felker
2020-05-13 18:49             ` John Arnold
2020-05-13 18:50               ` Rich Felker
2020-05-15  0:24             ` John Arnold
2020-05-13 19:36       ` Anders Magnusson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=698e1de6-2e35-0516-5637-6fb8f8273ce3@ludd.ltu.se \
    --to=ragge@ludd.ltu.se \
    --cc=dalias@aerifal.cx \
    --cc=iohannes.eduardus.arnold@gmail.com \
    --cc=musl@lists.openwall.com \
    --cc=pcc@lists.ludd.ltu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).