> 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.
I don't understand this security problem that you are referring to.
The vast majority of strings use 'char' as the element type.
Existing code might look something like this:
#define A "foo"
#define B "bar"
#define STRING_LEN(s) (sizeof(s) - 1)
char *c = malloc(STRING_LEN(A) + STRING_LEN(B) + 1);
if (c) {
strcpy(c, A);
strcat(c, B);
}
Supposing that _Length gets support in GCC, the equivalent source code would be
almost
identical and the compiled code would be identical:
#define A "foo"
#define B "bar"
#define STRING_LEN(s) (_Lengthof(s) - 1)
char *c = malloc(STRING_LEN(A) + STRING_LEN(B) + 1);
if (c) {
strcpy(c, A);
strcat(c, B);
}
Are you concerned that people will start writing new code that does something
like the following?
#define A "foo"
#define B "bar"
char *c = malloc(_Lengthof(A) + _Lengthof(B));
if (c) {
strcpy(c, A);
strcat(c, B);
}
If they do, the only consequence will be that the string buffer is longer than
it needs to be; not shorter.
Best regards,
--
Christopher Bazley
Staff Software Engineer, GPU team, Central Engineering Group
ARM Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
Web: http://www.arm.com/
________________________________
From: Alejandro Colomar
Sent: Tuesday, October 08, 2024 15:49
To: Jakub Jelinek
Cc: Joseph Myers; gcc-patches@gcc.gnu.org; Gabriel Ravier; Kees Cook; Qing
Zhao; Jens Gustedt; David Brown; Florian Weimer; Andreas Schwab; Timm Baeder;
Daniel Plakosh; A. Jiang; Eugene Zelenko; Aaron Ballman; Paul Koning; Daniel
Lundin; Nikolaos Strimpas; JeanHeyd Meneide; Fernando Borretti; Jonathan
Protzenko; Chris Bazley; Ville Voutilainen; Alex Celeste; Jakub Łukasiewicz;
Douglas McIlroy; Jason Merrill; Xavier Del Campo Romero; Siddhesh Poyarekar; DJ
Delorie; Carlos O'Donell; Stephen Coady; Robert Seacord
Subject: Re: [PATCH v13 0/4] c: Add __lengthof__ operator
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/>
