On Tue, Oct 08, 2024 at 03:40:53PM GMT, Jakub Jelinek wrote:
> On Tue, Oct 08, 2024 at 03:28:29PM +0200, Alejandro Colomar wrote:
> > On Tue, Oct 08, 2024 at 01:19:06PM GMT, Joseph Myers wrote:
> > > On Tue, 8 Oct 2024, Alejandro Colomar wrote:
> > > 
> > > > On Mon, Oct 07, 2024 at 05:35:16PM GMT, Joseph Myers wrote:
> > > > > Patches 1, 2 and 3 are logically nothing to do with this feature.  
> > > > > I'll 
> > > > > wait for them to be reviewed so that we only have a single-patch 
> > > > > series, 
> > > > > before doing final review of the main patch.
> > > > 
> > > > I do not fully understand.  Who has to review patches 1,2,3?  Also, do
> > > 
> > > Someone who is a maintainer or reviewer of relevant parts of the 
> > > compiler.  
> > > Maybe 90% of the people CC:ed are not GCC maintainers or reviewers and 
> > > should not be included on these patches at all.
> > 
> > Those are people with interest in one way or another in this feature
> > (most of them, patch 4).  While patches 1,2,3 are irrelevant to them, I
> > kept them on the entire thread for simplicity.
> 
> I'd just suggest posting the patch 4 alone adjusted so that it doesn't need
> 2,3.  Those 2 can be handled completely independently from patch 4 and for 1
> there is no dependency, it is just a random unrelated patch.

2,3 are needed for not making 4 read horribly.
1 is needed for the commit message of 4.

I don't mind waiting for gcc-16, if that needs to happen.

> 
> > > > you want to merge them, then I resend patch 4 as a single patch, and
> > > > then you review that one?  If so, that looks like a good plan to me.
> > > 
> > > Yes, patch 4 as a single patch.  With _Lengthof.  No other names, no 
> > > __countof__, no __lengthof__.  _Lengthof is a perfectly good name, no 
> > > need 
> > > to be gratuitously incompatible.
> > 
> > It is not gratuitously, IMO.  You already know my concerns about it;
> > please sed(1) yourself the name of the operator from these patches, and
> > append your signature below mine, if you want to rename it.  I won't do
> > that, for I think it introduces a security problem that will slowly
> > develop.
> > 
> > If you wish to wait for Graz to make sure there's no incompatibility
> > with ISO, that's another possibility.
> 
> I don't see why we'd need to wait for next WG14 meeting here, as the paper
> has been voted into the next standard draft, compilers can implement the
> feature,

Because I don't like the paper that has been voted into the standard.
I kind of presented that paper against my will.  I wish GCC merged the
feature with a different name, and forced the standard to reconsider
what they merged, which I consider to be a security problem.

Alternatively, I wish GCC decided to do nothing, wait for Graz, where
I'll try to convince WG14 to change what was voted.

But merging what was voted into the standard would be nefarious, IMO.


Have a lovely day!
Alex

> and as with anything else if the standard is changed later, it will
> be adjusted to match it (or withdrawn/renamed or whatever).  That is always
> a risk of using features from unreleased standards (but even features
> in released standards can be tweaked with DRs later on).
> It doesn't make sense to have two different operators just because we fear
> it will change.
> We do have some cases of different operators for the same thing if it was
> first implemented as an extension and only later standardized under
> different name or with different rules.
> That is not the case here.
> 
>       Jakub
> 

-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature

Reply via email to