On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote: > [Moved from gcc-patches@ to gcc@] > > Hi JeanHeyd, наб, > > I see you (JeanHeyd) are developing yet another survey about the names > for this new operator. Let me ask you to be clear about my fear of > ambiguity with null-terminated strings which are stored within arrays > and the length of both entities differ, usually by exactly one, being a > potential cause of a confusion that might result in buffer overflows, or > other kinds of errors (and it would be interesting to mention that I've > presented a link to an actual bug of that class in shadow-utils, which I > fixed recently). I would also like the survey to be presented to > programmers that like programming in C; I would refuse to acknowledge > the results of any survey that is presented to C++ or rust programmers > who acknowledge not wanting to program in C ever again. They have a > clear conflict of interest. If this survey is conducted, it should > include the gcc and glibc communities, and the resons why each name is
It would also be interesting to hear the opinion of people from the BSDs and Unix/Plan9. > considered good and bad should be clearly stated alongside the options, > in a detailed rationale. > > For extentof(), my only caveat is that one might want to add a 2-args > operator (or macro) that has the C++ semantics, that is, allowing you to > specify the dimension of the array that you want. I don't see why it > would be useful, but didn't want to preclude it either. But other than > that, I'm okay with that name. > > Another thing is that I'd prefer it to be based on email, or something > that doesn't impose a barrier to those who don't have an account in a > given platform, and don't want to create it. > > Thanks for your interest in this operator! > > Have a lovely day! > Alex > > > P.S.: наб, you asked why not array_size(). I agree with the defenders > of lengthof that size should not be overloaded to mean both the number > of bytes and the number of elements of an object (although I'm closer to > accepting overloading the term "size" than overloading the term > "length", since size at least doesn't promote off-by-one errors). Also, > I have a macro sizeof_array() which I define as > > #define sizeof_array(a) (countof(a) * sizeof((a)[0])) > > It would be very weird and confusing to have > > #define sizeof_array(a) (array_size(a) * sizeof((a)[0])) > > > > On Sat, Oct 26, 2024 at 12:10:56AM GMT, Alejandro Colomar wrote: > > Hi Joseph, > > > > On Fri, Oct 25, 2024 at 08:44:15PM GMT, Joseph Myers wrote: > > > I don't see the use of pedwarn_c23 and associated tests (error with > > > -std=c23 -pedantic-errors, warning with -std=c23 -pedantic, no diagnostic > > > with -std=c23 -pedantic-errors -Wno-c23-c2y-compat, no diagnostic with > > > -std=c2y -pedantic-errors, warning with -std=c2y -pedantic-errors > > > -Wc23-c2y-compat), previously discussed in comments on v13, that would be > > > appropriate before considering this for inclusion with an appropriate > > > substitution of names. > > > > I removed it because I renamed it to __countof__, which is a GNU > > extension, and thus should not be warned by -Wpedantic. As part of my > > opposition to _Lengthof, I will not provide you with that part, which > > would amount to basically giving you _Lengthof but not. As part of the > > editorialising process, you'll also have to add pedantic warnings, if > > that's what you want to do. Again, I will earnestly ask to once more to > > consider __countof__, but it's up to you. > > > > Have a lovely night! > > Alex > > > > -- > > <https://www.alejandro-colomar.es/> > > > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
