gcc-15-20241027 is now available

2024-10-27 Thread GCC Administrator via Gcc
Snapshot gcc-15-20241027 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/15-20241027/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision b281e13ecad12d07209924a7282c53be3a1c3774

You'll find:

 gcc-15-20241027.tar.xz   Complete GCC

  SHA256=8cf578ed01acd2fb8f86d6185cb75665d368bcd7f35e2211f18667ff668abfeb
  SHA1=90a530420131571369204036a02cfc921a187e9d

Diffs from 15-20241020 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-15
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-27 Thread Thorsten Glaser
Alejandro Colomar dixit:

>Yes; there are four n papers.  See below, plus the history of why
>four papers.

Thanks, will look at them but probably on Tuesday.

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

Ah, okay.

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

I fear we share this property but I can try to reach out via
Miod, he might have an idea, and via bsiegert to NetBSD.

bye,
//mirabilos


Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-27 Thread Alejandro Colomar via Gcc
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 n.pdf link
> handy? I don’t actively follow C other than what thephd posts.

Yes; there are four n papers.  See below, plus the history of why
four papers.




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:

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.



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.



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



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

-- 



signature.asc
Description: PGP signature


Re: [PATCH v17 2/2] c: Add __countof__ operator

2024-10-27 Thread Alejandro Colomar via Gcc
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 n.pdf link
> > handy? I don’t actively follow C other than what thephd posts.
> 
> Yes; there are four n papers.  See below, plus the history of why
> four papers.
> 
> 
> 
> 
> 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:
> 
> 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.
> 
> 
> 
> 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.
> 
> 
> 
> 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.
> 
> 
> 
> 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