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=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 9705 invoked from network); 27 Jun 2023 22:01:06 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2023 22:01:06 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Tue Jun 27 17:57:56 -0400 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1687902907;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=bB30w9R3E51tJrY1lM/ySmzC835YlZeQX3F0GQpX+K0=;
	b=Pns4DcYcGu2yVdKJWtr4MOWMKeRCkEK7WvW4f2fn5C4D+rFf0/JMtMkMYwp9zsAMMxd3Vh
	aL0a6K0JA4cygRUm31igdz5dzEawXPuNhsav3ylYZYJlrRUyeBHawMqH1IG9bFcsEqiaJ0
	W3izmgbCh7klx75zTBI2cZN8xf4vglo=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 6bcbf165 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Tue, 27 Jun 2023 14:55:06 -0700 (PDT)
Message-ID: <06BB44D4C410A6B67D4C15A6D7D6B7BA@wopr.sciops.net>
Date: Tue, 27 Jun 2023 23:57:50 +0200
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <6029838c-c0b3-8956-8ac9-4638bef72241@posixcafe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: cache-scale rich-client replication 
Subject: Re: [9front] Re: cc: support binary constants and refactor
Reply-To: 9front@9front.org
Precedence: bulk

On Tue Jun 27 14:35:47 +0200 2023, moody@mail.posixcafe.org wrote:
> On 6/27/23 01:26, qwx@sciops.net wrote:
> > Hi all,
> > 
> >> Subject: [PATCH] cc: support binary constants and refactor
> >>
> >>
> >> C23 now specifies 0[bB] binary constants.
> >> In adding these cinap found that the bounds
> >> checking in mpatov() was incorrect, both in
> >> implementation and concept. So instead lets
> >> just accumulate the constant value as we lex.
> >
> > What's the motivation behind adding this?
> 
> I thought they were useful, saw they were being
> standardized, and the code change turned out quite small.
> That's the only reasoning.
[...]
> > Is it just for ports?
> 
> It was not added for any specific port. I added it because I thought they were
> useful.

Thanks; frankly I'm asking because I'm then a bit sceptical as to the
utility of this.  What I mean is that there are plenty of deficiencies
in C, but this seems like minor syntactic sugar; what else is it
alright to add, even if we don't have to care about compatibility etc?
But it's already in the tree, and I guess that's similar to adding
rc(1) features or syntax, and I don't complain about that, so
whatever.  I'm not sure I'm making sense here.


> > Either way, perhaps we should at least update 2c(1) to list
> > this and other non ANSI stuff that may have been added in the past few
> > years (noreturn, #pragma once recently).
> 
> Sure, something can be put in to 2c(1) regarding these, although a
> lot of these details hide out in /sys/src/cmd/cc/c99.

I think it's useful to have an up-to-date document to point to that
lists these kinds of additions.  I could perhaps go through the
changelog and write a patch when I find the time.

Anyway, thanks and cheers,
qwx