[9front] Re: cc: support binary constants and refactor

[9front] Re: cc: support binary constants and refactor

[qwx]

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?  Are other features from
newer standards considered for inclusion as well?  Is it just for
ports?  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).

Thanks,
qwx

Re: [9front] Re: cc: support binary constants and refactor

[Jacob Moody]

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.

> Are other features from newer standards considered for inclusion as well?

If they are useful sure. I am not interested in picking up everything, I just want
the things I will use.

> Is it just for ports?  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).

It was not added for any specific port. I added it because I thought they were
useful. 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.

Re: [9front] Re: cc: support binary constants and refactor

[qwx]

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

Re: [9front] Re: cc: support binary constants and refactor

[Jacob Moody]

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.

Re: [9front] Re: cc: support binary constants and refactor

[qwx]

On Wed Jun 28 02:17:19 +0200 2023, moody@mail.posixcafe.org wrote:
> On 6/27/23 16:57, qwx@sciops.net wrote:
> > 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.

There's no need to revert anything, I was just wondering what the
rationale was; I haven't seen discussions about it.  If it sounded
like an attack, I apologize.


> > 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.

I'll just come back to this with a patch or a list (no promises),
it'll be easier to discuss what to put and what not.

Thanks,
qwx

Re: [9front] Re: cc: support binary constants and refactor

[Jacob Moody]

On 6/27/23 19:45, qwx@sciops.net wrote:
> On Wed Jun 28 02:17:19 +0200 2023, moody@mail.posixcafe.org wrote:
>> On 6/27/23 16:57, qwx@sciops.net wrote:
>>> 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.
> 
> There's no need to revert anything, I was just wondering what the
> rationale was; I haven't seen discussions about it.  If it sounded
> like an attack, I apologize.

I didn't view it as an attack. We just seem to disagree on how useful
the feature is. That's totally fine, but it's one of those things that
you can't really convince each other about, you either see yourself using
it or not. It's at this point I offer to revert to see if my opinion is
not in line with the majority here. I don't view that as a bad thing, these
types of checks on what we add are good, reverts are cheap, shit happens.

This patch was implemented, discussed and committed while hanging out on the
jitsi last weekend. I don't know what the reasonable "airing" of ideas are
before I just commit. I generally consider anything that I run past cinap
good enough, and then just revert later if more people disagree then not.
If there are other criteria I should hold myself to, let me know.

Clearly something has to change because I have a pattern now of getting
called out to explain my thinking under skepticism that I fucked up.

Re: [9front] Re: cc: support binary constants and refactor

[ori]

Quoth qwx@sciops.net:
> On Wed Jun 28 02:17:19 +0200 2023, moody@mail.posixcafe.org wrote:
> > On 6/27/23 16:57, qwx@sciops.net wrote:
> > > 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.
> 
> There's no need to revert anything, I was just wondering what the
> rationale was; I haven't seen discussions about it.  If it sounded
> like an attack, I apologize.
> 

while it's a bit surprising to me that you find binary constants
useful (I've never really reached for them), it's a trivial feature
that's already been standardized, and doesn't interact with much.

*shrug* seems good to me.

Re: [9front] Re: cc: support binary constants and refactor

[Noam Preil]

I third this.

I don't find myself reaching for them often, but it's sometimes nice
when e.g. working on an emulator to be able to specify bitflags as a
binary string instead of hex; it makes it easier to decode what the heck
the flags are actually being set to, for instance!

It breaks nothing, is standardized, eases porting, and is occasionally
useful; why not add it?

Re: [9front] Re: cc: support binary constants and refactor

[hiro]

i never understood why it didn't exist.
if i implement stuff straight from the spec i like to copy&paste the
spec into a comment, then implement it the dumb way 1:1.
so far i always manually converted everything into hex, which is retarded IMO.

On 6/28/23, Noam Preil <noam@pixelhero.dev> wrote:
> I third this.
>
> I don't find myself reaching for them often, but it's sometimes nice
> when e.g. working on an emulator to be able to specify bitflags as a
> binary string instead of hex; it makes it easier to decode what the heck
> the flags are actually being set to, for instance!
>
> It breaks nothing, is standardized, eases porting, and is occasionally
> useful; why not add it?
>
>