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