Re: Expose 'array_length()' macro in

2020-09-21 Thread Ville Voutilainen via Gcc
On Tue, 22 Sep 2020 at 01:07, Jonathan Wakely via Libstdc++ wrote: > ># define array_length(arr)(std:size(arr)) > > C++ programmers will not accept a macro for this. ..in other words, the C++17 version of it needs to be an inline function that returns std::size of an array, not a macro. All

Re: [libc-coord] Re: Expose 'array_length()' macro in or

2020-09-22 Thread Ville Voutilainen via Gcc
On Tue, 22 Sep 2020 at 19:46, Jonathan Wakely via Libstdc++ wrote: > > On 22/09/20 12:25 -0400, Rich Felker wrote: > >Is there really a reason to want a nonstandard macro like this to do > >something that's already trivial to do in the base language and has a > >standard idiom (sizeof x / sizeof *

Re: [RFC] Increase libstdc++ line length to 100(?) columns

2020-11-27 Thread Ville Voutilainen via Gcc
On Fri, 27 Nov 2020 at 10:16, Richard Biener via Libstdc++ wrote: > > Why not change this to: > > > > > if (present) > > > ptr = gfc_build_conditional_assign_expr ( > > > block, present, ptr, nullarg); > > > > > > > I think

Re: [RFC] Increase libstdc++ line length to 100(?) columns

2020-11-27 Thread Ville Voutilainen via Gcc
On Fri, 27 Nov 2020 at 11:54, Liu Hao via Libstdc++ wrote: > As you can see, qualified names in C++ can grow up to ~100 characters quite > frequently. This may > deteriorate when `typename` and `template` are sometimes required. I don't > think there is > practically a set of rules which governs

Remove RMS from the GCC Steering Committee

2021-03-30 Thread Ville Voutilainen via Gcc
Giacomo wrote: >Stallman cannot betray Free Software AND get away with it. >So to me (and to many others) Stallman is a sort of a living warranty. That's fine. He doesn't need to be in the GCC SC to do that. He can continue to provide guidance on the spirit of Free Software without having an SC p

GCC association with the FSF

2021-04-11 Thread Ville Voutilainen via Gcc
>However, the FSF does NOT control nor own the GNU project. That appears to be a very common misperception. >The FSF offers various pro-bono services to the GNU project, among them guarding some GNU assets for the GNU project, but the GNU project is an independent (unincorporated) organization, w

A suggestion for going forward from the RMS/FSF debate

2021-04-16 Thread Ville Voutilainen via Gcc
Huge apologies for mis-sending this to gcc-patches, my email client makes suggestions when I attempt to send to a gcc list. :D The actual suggestion is at the end; skip straight to it if you wish. >Im glad there are people like you on the project Eric, because you express exactly what a lot of pe

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-16 Thread Ville Voutilainen via Gcc
On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > The "small minority of developers" you speak of sure > > seems to consist of developers who are not in the minority > > considering how much they _actually contribute_ to the project. > > Due to their being paid for the work. Have no dou

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-16 Thread Ville Voutilainen via Gcc
On Fri, 16 Apr 2021 at 16:22, Christopher Dimech wrote: > Many do not contribute because they do not have time, resources or support. Yes? And? Even if GCC detaches itself from FSF, those who can contribute will continue to contribute. And those who talk about contributing but don't contribute wi

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-17 Thread Ville Voutilainen via Gcc
On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote: > > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc > wrote: > > > Sent: Saturday, April 17, 2021 at 1:03 AM > > > From: "Ville Voutilainen" > > > To: "Christopher Dimech" > > > Cc: "GCC Development" > > > Subject: Re: A suggestion

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-17 Thread Ville Voutilainen via Gcc
On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: > I do not see people really intending to fork. It explains why detractors > have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous t

Re: A suggestion for going forward from the RMS/FSF debate

2021-04-18 Thread Ville Voutilainen via Gcc
On Sun, 18 Apr 2021 at 13:49, Richard Kenner wrote: > > > Depends on the use cases. Not in military surveillance. And certainly not > > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > > I'm not sure. Before 2011, rather than building things from scratch, > > washi