On Sun, Oct 27, 2024 at 02:00:01PM GMT, Alejandro Colomar wrote: > Hi Thorsten, > > On Sun, Oct 27, 2024 at 04:30:43AM GMT, Thorsten Glaser wrote: > > Hi Alejandro, > > > > >On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote: > > >> Not too sure what the root context of this thread is, but in BSD land > > > > > >The root context is that > > > > > >- _Lengthof was added to C2y in the Minnesota meeting. It was proposed > > > > where/how would this be used for? Also, do you have the nXXXX.pdf link > > handy? I don’t actively follow C other than what thephd posts. > > Yes; there are four nXXXX papers. See below, plus the history of why > four papers. > > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2529.pdf> > > That first paper wasn't mine. I didn't know about the existence of that > paper until a few months after that paper I sent a patch to glibc adding > the usual macro, and I think Joseph told me about the existence of the > paper. I tried to contact the author of the paper, to ask him to change > the name, since I thought it would be dangerous as I said here. I > couldn't reach him in many years, so at some point I decided I would > author a revision of the paper. > > I believe stuff should go into the standard after it exists in an > implementation, so I first prepared a patch for GCC: > <https://inbox.sourceware.org/gcc-patches/20240728141547.302478-1-...@kernel.org/T/#t> > Joseph Myers asked me to present a paper to WG14 to see what they think > before he would finish the review of my patch set, and so I prepared the > paper, which was submitted as n3313. By the time I wrote this GCC > patch, I had relaxed my feelings about the dangers of the name > _Lengthof, so I didn't think too much about it and followed the original > proposal, also since Martin Uecker --who helped me develop the GCC > patch set-- had a preference for that name. > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3313.pdf> > > While iterating on the patches, at some point I reminded myself of > actual bugs I had fixed in the recent past in which precisely this > naming confusion was involved. I decided to rename the operator to > _Nelementsof, to avoid having the term length, and because the standard > uses quite often the terms "number of elements in an array" and "one > past the last element of an array object", so it just felt the natural > term to use. Since the name of the operator was too long, and some > people complained about that, I proposed an alternative name _Neltsof. > I then submitted n3325. > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3325.pdf> > > The paper was discussed in the Minnesota meeting of WG14, where I was > invited to defend my paper. The semantics were agreed upon, but there > wasn't strong consensus on the name. In the end, _Nelementsof was > rejected in a poll with majority but no consensus (only slightly more > YESs than NOs). Then we voted to see what name should be used, and the
Oops; only slightly _less_ YESs than NOs. > name _Lengthof was voted. I had to present n3369. > > I wasn't the only voice concerned about _Lengthof. The name _Countof > seemed to have also some traction in the people that didn't want > _Lengthof, so it's the name I'm considering now, but either something > derived from _Nelementsof or _Countof or anything not "length"y would be > good IMO. > > BTW, during the discussions, _Nelemsof seemed to be strongly preferred > over _Neltsof. I don't care at all about those trivial details, though. > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3369.pdf> > > And this paper was voted in for C2y, so here we are. I'm still trying > to overrule that paper by implementing it with a different name. Since > I have the advantage that I already have the patches working, I have > months before anybody implements _Lengthof in another compiler and sets > the name in stone. > > It would be great if authors of other compilers would agree on the > dangerousness of this name and pushed for a different name. > > > >- I'm sending a patch to GCC proposing __countof__, since overloading > > > length for both string length and array number of elements is (IMO) > > > going to promote off-by-one bugs in string-handling code (and I've > > > > Definitely! The string length is one less than the amount of array > > elements it has (works for char and wide strings). > > Thanks! > > > >- _Nelementsof > > >- _Nelemsof > > > > If you want to shorten elements, elts is probably seen more > > often than elems, at least in my experience. But this is very > > low-grade bikeshedding, so just me pointing it out but putting > > not much weight behind it. > > That was my original proposal, but everybody I've talked so far told me > they preferred _Nelemsof. I don't care about it at all, so whatever. > > > bye, > > //mirabilos > > PS: Got any contacts in the OpenBSD and NetBSD worlds that can > > add input? They invest a lot into good C code as well, in > > the OpenBSD case rather heavily (if opinionated). > > I don't. If you do, please let them know. Theo doesn't seem to have a > good opinion of me, but maybe he could help. > > Have a lovely day! > Alex > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
