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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14573 invoked from network); 28 Jun 2023 00:21:03 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 28 Jun 2023 00:21:03 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Tue Jun 27 20:15:46 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1687911485; 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:references:references; bh=R9WwzuIk4fG2L4AFzLSrXJTIt2T0vjai6fjNKVSQiT4=; b=b9zOtdUQKMUf6Vv2+MSjWBkObDCxXEBZvMTfJtSx4J2mNCHEjqMh1tblfxB/WNqrGNHz4P 0dXuqntF/stOocNpldPfPWpf0rbeNVlU+wtUnU82CMMxDRuUEaEEJkDNzYnmXlBjZnNUzh U8bUwcXQ2lttFo1jggob2YhD3C8uVTE= Received: from [192.168.168.123] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id ca4671bb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Tue, 27 Jun 2023 19:18:05 -0500 (CDT) Message-ID: <91c88c76-7b72-22b8-d9b4-f74171269875@posixcafe.org> Date: Tue, 27 Jun 2023 19:15:43 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Content-Language: en-US To: 9front@9front.org References: <06BB44D4C410A6B67D4C15A6D7D6B7BA@wopr.sciops.net> From: Jacob Moody In-Reply-To: <06BB44D4C410A6B67D4C15A6D7D6B7BA@wopr.sciops.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: RESTful polling HTML framework-oriented interface injection framework Subject: Re: [9front] Re: cc: support binary constants and refactor Reply-To: 9front@9front.org Precedence: bulk On 6/27/23 16:57, qwx@sciops.net wrote: > 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. > It seems your bar for useful is "fixing a deficiency in C". My bar for this was: standard, cheap and something I have found myself reaching for. I got used to having it around in go. That should answer your question for what I consider "fine to add". If my thinking here is incorrect we can revert and keep just the bugfix, things are not final because they get put in tree. > >>> 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. > Sure, better docs would be great. There are also the undocumented kencc magic features like signof(?) and the operator overloading stuff. I dont think we need to spell out every standard feature we have, some of this stuff can be assumed.