* Warning for C Parameter Name Mismatch @ 2019-03-08 22:25 Joel Sherrill 2019-03-08 23:06 ` Joseph Myers 2019-03-28 6:07 ` Eric Gallager 0 siblings, 2 replies; 14+ messages in thread From: Joel Sherrill @ 2019-03-08 22:25 UTC (permalink / raw) To: GCC Hi This may be just an ignorant user question on my part. Can gcc report when the parameter name in a C prototype does not match that used in the implementation? int f(int x); int f(int y) {...} We try to fix every warning gcc reports but this is one that gcc doesn't report for us. It could be we need an extra -Wxxx but we end up spotting these with Doxygen. Anything we are missing? Thanks. --joel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-08 22:25 Warning for C Parameter Name Mismatch Joel Sherrill @ 2019-03-08 23:06 ` Joseph Myers 2019-03-08 23:36 ` David Brown 2019-03-28 6:07 ` Eric Gallager 1 sibling, 1 reply; 14+ messages in thread From: Joseph Myers @ 2019-03-08 23:06 UTC (permalink / raw) To: Joel Sherrill; +Cc: GCC On Fri, 8 Mar 2019, Joel Sherrill wrote: > Can gcc report when the parameter name in a C prototype > does not match that used in the implementation? > > int f(int x); > > int f(int y) {...} I think this would be normal and expected - an installed header would use a reserved-namespace name for the parameter while the implementation uses a non-reserved name that's more convenient for use within the implementation. (Thus anything like this would only be useful if it can know that it's e.g. OK to have __y and y as the names, and some code no doubt uses other such conventions relating the two names.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-08 23:06 ` Joseph Myers @ 2019-03-08 23:36 ` David Brown 2019-03-09 2:23 ` Eric Gallager 0 siblings, 1 reply; 14+ messages in thread From: David Brown @ 2019-03-08 23:36 UTC (permalink / raw) To: Joseph Myers, Joel Sherrill; +Cc: GCC On 09/03/2019 00:06, Joseph Myers wrote: > On Fri, 8 Mar 2019, Joel Sherrill wrote: > >> Can gcc report when the parameter name in a C prototype >> does not match that used in the implementation? >> >> int f(int x); >> >> int f(int y) {...} > > I think this would be normal and expected - an installed header would use > a reserved-namespace name for the parameter while the implementation uses > a non-reserved name that's more convenient for use within the > implementation. (Thus anything like this would only be useful if it can > know that it's e.g. OK to have __y and y as the names, and some code no > doubt uses other such conventions relating the two names.) > I can appreciate that a warning like this is not for everyone. But /I/ would like and use such a warning for my own code. The kind of headers which would specifically use reserved or otherwise unusual parameter names are things like library headers - and you will not be compiling the implementation source code, and thus won't get a mismatch. A warning like this would be used with your own header/source combinations - where your implementation is #include'ing the unit's header as a way of checking that you've got the function name and parameter types correct. This warning would add parameter names to the things that are checked. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-08 23:36 ` David Brown @ 2019-03-09 2:23 ` Eric Gallager 2019-03-09 8:30 ` Jonathan Wakely 2019-03-09 12:22 ` David Brown 0 siblings, 2 replies; 14+ messages in thread From: Eric Gallager @ 2019-03-09 2:23 UTC (permalink / raw) To: David Brown; +Cc: Joseph Myers, Joel Sherrill, GCC On 3/8/19, David Brown <david.brown@hesbynett.no> wrote: > On 09/03/2019 00:06, Joseph Myers wrote: >> On Fri, 8 Mar 2019, Joel Sherrill wrote: >> >>> Can gcc report when the parameter name in a C prototype >>> does not match that used in the implementation? >>> >>> int f(int x); >>> >>> int f(int y) {...} >> >> I think this would be normal and expected - an installed header would use >> a reserved-namespace name for the parameter while the implementation uses >> a non-reserved name that's more convenient for use within the >> implementation. (Thus anything like this would only be useful if it can >> know that it's e.g. OK to have __y and y as the names, and some code no >> doubt uses other such conventions relating the two names.) >> > > I can appreciate that a warning like this is not for everyone. But /I/ > would like and use such a warning for my own code. > > The kind of headers which would specifically use reserved or otherwise > unusual parameter names are things like library headers - and you will > not be compiling the implementation source code, and thus won't get a > mismatch. A warning like this would be used with your own header/source > combinations - where your implementation is #include'ing the unit's > header as a way of checking that you've got the function name and > parameter types correct. This warning would add parameter names to the > things that are checked. > > How would it handle the case where the parameter name is missing entirely from the prototype? I see a lot of header files with their prototypes written like that. e.g. int f(int); int f(int y) {...} ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-09 2:23 ` Eric Gallager @ 2019-03-09 8:30 ` Jonathan Wakely 2019-03-09 17:27 ` Segher Boessenkool 2019-03-09 12:22 ` David Brown 1 sibling, 1 reply; 14+ messages in thread From: Jonathan Wakely @ 2019-03-09 8:30 UTC (permalink / raw) To: Eric Gallager; +Cc: David Brown, Joseph S. Myers, Joel Sherrill, GCC On Sat, 9 Mar 2019, 02:23 Eric Gallager, <egall@gwmail.gwu.edu> wrote: > On 3/8/19, David Brown <david.brown@hesbynett.no> wrote: > > On 09/03/2019 00:06, Joseph Myers wrote: > >> On Fri, 8 Mar 2019, Joel Sherrill wrote: > >> > >>> Can gcc report when the parameter name in a C prototype > >>> does not match that used in the implementation? > >>> > >>> int f(int x); > >>> > >>> int f(int y) {...} > >> > >> I think this would be normal and expected - an installed header would > use > >> a reserved-namespace name for the parameter while the implementation > uses > >> a non-reserved name that's more convenient for use within the > >> implementation. (Thus anything like this would only be useful if it can > >> know that it's e.g. OK to have __y and y as the names, and some code no > >> doubt uses other such conventions relating the two names.) > >> > > > > I can appreciate that a warning like this is not for everyone. But /I/ > > would like and use such a warning for my own code. > > > > The kind of headers which would specifically use reserved or otherwise > > unusual parameter names are things like library headers - and you will > > not be compiling the implementation source code, and thus won't get a > > mismatch. A warning like this would be used with your own header/source > > combinations - where your implementation is #include'ing the unit's > > header as a way of checking that you've got the function name and > > parameter types correct. This warning would add parameter names to the > > things that are checked. > > > > > > How would it handle the case where the parameter name is missing > entirely from the prototype? I see a lot of header files with their > prototypes written like that. > > e.g. > > int f(int); > > int f(int y) {...} > I don't think that's valid in C, only C++, and I would expect no warning for such cases. But I don't see much value in the suggested warning at all. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-09 8:30 ` Jonathan Wakely @ 2019-03-09 17:27 ` Segher Boessenkool 2019-03-09 17:51 ` Joel Sherrill 2019-03-11 11:26 ` Jonathan Wakely 0 siblings, 2 replies; 14+ messages in thread From: Segher Boessenkool @ 2019-03-09 17:27 UTC (permalink / raw) To: Jonathan Wakely Cc: Eric Gallager, David Brown, Joseph S. Myers, Joel Sherrill, GCC On Sat, Mar 09, 2019 at 08:30:19AM +0000, Jonathan Wakely wrote: > On Sat, 9 Mar 2019, 02:23 Eric Gallager, <egall@gwmail.gwu.edu> wrote: > > How would it handle the case where the parameter name is missing > > entirely from the prototype? I see a lot of header files with their > > prototypes written like that. > > > > e.g. > > > > int f(int); > > > > int f(int y) {...} > > I don't think that's valid in C, only C++, and I would expect no warning > for such cases. But I don't see much value in the suggested warning at all. This is perfectly fine C. Parameter names are optional in prototypes. It's different if it is the function definition, I think that is what you mean? Segher ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-09 17:27 ` Segher Boessenkool @ 2019-03-09 17:51 ` Joel Sherrill 2019-03-11 11:35 ` Jonathan Wakely 2019-03-11 11:26 ` Jonathan Wakely 1 sibling, 1 reply; 14+ messages in thread From: Joel Sherrill @ 2019-03-09 17:51 UTC (permalink / raw) To: Segher Boessenkool Cc: Jonathan Wakely, Eric Gallager, David Brown, Joseph S. Myers, GCC On Sat, Mar 9, 2019, 11:27 AM Segher Boessenkool <segher@kernel.crashing.org> wrote: > On Sat, Mar 09, 2019 at 08:30:19AM +0000, Jonathan Wakely wrote: > > On Sat, 9 Mar 2019, 02:23 Eric Gallager, <egall@gwmail.gwu.edu> wrote: > > > How would it handle the case where the parameter name is missing > > > entirely from the prototype? I see a lot of header files with their > > > prototypes written like that. > > > > > > e.g. > > > > > > int f(int); > > > > > > int f(int y) {...} > > > > I don't think that's valid in C, only C++, and I would expect no warning > > for such cases. But I don't see much value in the suggested warning at > all. > > This is perfectly fine C. Parameter names are optional in prototypes. > It's different if it is the function definition, I think that is what > you mean? > That's how I read it and that would not be a warning IMO. Back to a point in my original email that seems to have been missed. Doxygen reports this as a warning. I would just like the option to find it with gcc as well. And not checking system headers is reasonable in general. For RTEMS though, we are implementing those system headers and do follow the names in the standards for parameter names in the implementation. --joel > > > Segher > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-09 17:51 ` Joel Sherrill @ 2019-03-11 11:35 ` Jonathan Wakely 0 siblings, 0 replies; 14+ messages in thread From: Jonathan Wakely @ 2019-03-11 11:35 UTC (permalink / raw) To: Joel Sherrill Cc: Segher Boessenkool, Eric Gallager, David Brown, Joseph S. Myers, GCC On Sat, 9 Mar 2019 at 17:51, Joel Sherrill wrote: > And not checking system headers is reasonable in general. For RTEMS though, we are implementing those system headers and do follow the names in the standards for parameter names in the implementation. Using exactly the names from the standard is non-conforming, because they aren't reserved names and so this valid code would fail to compile: #define format 1 #include <stdio.h> int main() { printf("%d\n", format); } ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-09 17:27 ` Segher Boessenkool 2019-03-09 17:51 ` Joel Sherrill @ 2019-03-11 11:26 ` Jonathan Wakely 1 sibling, 0 replies; 14+ messages in thread From: Jonathan Wakely @ 2019-03-11 11:26 UTC (permalink / raw) To: Segher Boessenkool Cc: Eric Gallager, David Brown, Joseph S. Myers, Joel Sherrill, GCC On Sat, 9 Mar 2019 at 17:27, Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Sat, Mar 09, 2019 at 08:30:19AM +0000, Jonathan Wakely wrote: > > On Sat, 9 Mar 2019, 02:23 Eric Gallager, <egall@gwmail.gwu.edu> wrote: > > > How would it handle the case where the parameter name is missing > > > entirely from the prototype? I see a lot of header files with their > > > prototypes written like that. > > > > > > e.g. > > > > > > int f(int); > > > > > > int f(int y) {...} > > > > I don't think that's valid in C, only C++, and I would expect no warning > > for such cases. But I don't see much value in the suggested warning at all. > > This is perfectly fine C. Parameter names are optional in prototypes. > It's different if it is the function definition, I think that is what > you mean? Ah yes, sorry for the noise. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-09 2:23 ` Eric Gallager 2019-03-09 8:30 ` Jonathan Wakely @ 2019-03-09 12:22 ` David Brown 1 sibling, 0 replies; 14+ messages in thread From: David Brown @ 2019-03-09 12:22 UTC (permalink / raw) To: Eric Gallager; +Cc: Joseph Myers, Joel Sherrill, GCC On 09/03/2019 03:23, Eric Gallager wrote: > On 3/8/19, David Brown <david.brown@hesbynett.no> wrote: >> On 09/03/2019 00:06, Joseph Myers wrote: >>> On Fri, 8 Mar 2019, Joel Sherrill wrote: >>> >>>> Can gcc report when the parameter name in a C prototype >>>> does not match that used in the implementation? >>>> >>>> int f(int x); >>>> >>>> int f(int y) {...} >>> >>> I think this would be normal and expected - an installed header would use >>> a reserved-namespace name for the parameter while the implementation uses >>> a non-reserved name that's more convenient for use within the >>> implementation. (Thus anything like this would only be useful if it can >>> know that it's e.g. OK to have __y and y as the names, and some code no >>> doubt uses other such conventions relating the two names.) >>> >> >> I can appreciate that a warning like this is not for everyone. But /I/ >> would like and use such a warning for my own code. >> >> The kind of headers which would specifically use reserved or otherwise >> unusual parameter names are things like library headers - and you will >> not be compiling the implementation source code, and thus won't get a >> mismatch. A warning like this would be used with your own header/source >> combinations - where your implementation is #include'ing the unit's >> header as a way of checking that you've got the function name and >> parameter types correct. This warning would add parameter names to the >> things that are checked. >> >> > > How would it handle the case where the parameter name is missing > entirely from the prototype? I see a lot of header files with their > prototypes written like that. > > e.g. > > int f(int); > > int f(int y) {...} > That would be a warning, I would say. int f(int); int f(int) { ... } would be fine in C++. (And maybe allowed as a gcc extension in C?) To me, this whole thing has two purposes. It is to encourage consistency and avoid errors like having "moveto(int x, int y)" in the header and "moveto(int y, int x)" in the implementation file. It is not nearly as good as named parameters would be, but it's a step forward. The other point is to make headers more self-documenting. I see a missing parameter name in a declaration as missing essential information, and I don't want to see that in headers for code I am writing or responsible for. (The exception being when the parameter is not actually used, but exists for overloading or for compatibility with specific function types - in which case it is good that it is unnamed.) (This is just what /I/ want - I know other people might want different things.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-08 22:25 Warning for C Parameter Name Mismatch Joel Sherrill 2019-03-08 23:06 ` Joseph Myers @ 2019-03-28 6:07 ` Eric Gallager 1 sibling, 0 replies; 14+ messages in thread From: Eric Gallager @ 2019-03-28 6:07 UTC (permalink / raw) To: joel; +Cc: GCC On 3/8/19, Joel Sherrill <joel@rtems.org> wrote: > Hi > > This may be just an ignorant user question on my part. > > Can gcc report when the parameter name in a C prototype > does not match that used in the implementation? > > int f(int x); > > int f(int y) {...} > > We try to fix every warning gcc reports but this is one that gcc > doesn't report for us. It could be we need an extra -Wxxx but > we end up spotting these with Doxygen. > > Anything we are missing? > > Thanks. > > --joel > I found bug 79022 which seems relevant to this conversation: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <1552168709.15796.ezmlm@gcc.gnu.org>]
* Re: Warning for C Parameter Name Mismatch [not found] <1552168709.15796.ezmlm@gcc.gnu.org> @ 2019-03-10 6:11 ` Basile Starynkevitch 2019-03-10 11:54 ` David Brown 0 siblings, 1 reply; 14+ messages in thread From: Basile Starynkevitch @ 2019-03-10 6:11 UTC (permalink / raw) To: gcc; +Cc: Joel Sherrill (I am reading the GCC mailing list in digest mode) On 3/9/19 10:58 PM, gcc-digest-help@gcc.gnu.org wrote: > > On Fri, 8 Mar 2019, Joel Sherrill wrote: > >> Can gcc report when the parameter name in a C prototype >> does not match that used in the implementation? >> >> int f(int x); >> >> int f(int y) {...} > I think this would be normal and expected - an installed header would use > a reserved-namespace name for the parameter while the implementation uses > a non-reserved name that's more convenient for use within the > implementation. (Thus anything like this would only be useful if it can > know that it's e.g. OK to have __y and y as the names, and some code no > doubt uses other such conventions relating the two names.) > I can appreciate that a warning like this is not for everyone. But > /I/ would like and use such a warning for my own code. May I remind to all that this is a typical case for you writing a GCC plugin. You want a warning that few other people want, and that warning is tied to your particular coding style. You could avoid that warning by avoid naming the parameters in your header files, so you would declare int f (int /*x*/); in your header file. You might want to get a warning, but since it is not of general use (as many explained, not using the same name in the header and in the implementation of a given function parameter makes a lot of sense in general, even if you dislike such as style) you really should consider writing your own GCC plugin for that purpose. How to write such a GCC plugin is a different question, and should be asked as such. Cheers. -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-10 6:11 ` Basile Starynkevitch @ 2019-03-10 11:54 ` David Brown 2019-03-10 12:05 ` Basile Starynkevitch 0 siblings, 1 reply; 14+ messages in thread From: David Brown @ 2019-03-10 11:54 UTC (permalink / raw) To: Basile Starynkevitch, gcc; +Cc: Joel Sherrill On 10/03/2019 07:11, Basile Starynkevitch wrote: > > (I am reading the GCC mailing list in digest mode) > > On 3/9/19 10:58 PM, gcc-digest-help@gcc.gnu.org wrote: > >> >> On Fri, 8 Mar 2019, Joel Sherrill wrote: >> >>> Can gcc report when the parameter name in a C prototype >>> does not match that used in the implementation? >>> >>> int f(int x); >>> >>> int f(int y) {...} >> I think this would be normal and expected - an installed header would use >> a reserved-namespace name for the parameter while the implementation uses >> a non-reserved name that's more convenient for use within the >> implementation. (Thus anything like this would only be useful if it can >> know that it's e.g. OK to have __y and y as the names, and some code no >> doubt uses other such conventions relating the two names.) >> I can appreciate that a warning like this is not for everyone. But >> /I/ would like and use such a warning for my own code. > May I remind to all that this is a typical case for you writing a GCC > plugin. You want a warning that few other people want, and that warning > is tied to your particular coding style. > > You could avoid that warning by avoid naming the parameters in your > header files, so you would declare > int f (int /*x*/); in your header file. > > You might want to get a warning, but since it is not of general use (as > many explained, not using the same name in the header and in the > implementation of a given function parameter makes a lot of sense in > general, even if you dislike such as style) you really should consider > writing your own GCC plugin for that purpose. > > How to write such a GCC plugin is a different question, and should be > asked as such. > > Cheers. > I fully agree that this is not a warning everyone will want - but I disagree with the idea that it is a specialist or unusual warning. Remember, no one is asking for it to be in -Wall or -Wextra. gcc has many, many warnings available, and a large proportion of them will only be useful to a small proportion of users. You could certainly say that of things like "-Wmissing-prototypes", "-Wmissing-declarations" and "-Wredundant-decls". I fail to see that this suggestion is at all different. In particular, I see this warning being of little use for large C / C++ applications with code split into multiple libraries. But I see it as being of a good deal of use in small-systems embedded programming where you have a smaller code base, all compiled together in one project, and where coding conventions and styles are often strict. That will apply to only a very small proportion of people programming for x86-64 targets - but a very high proportion of those programming for AVR, msp430, ARM Cortex-M, and most of the other targets of gcc. It is easy to forget or underestimate the huge range of types of programming done with gcc - there are many of us for whom warnings like this would be a useful tool. However, you are right that plugins could be a way to achieve this. I think the Python plugin could be a good way to prototype features like this - and if it is useful, then it could be moved into gcc main. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Warning for C Parameter Name Mismatch 2019-03-10 11:54 ` David Brown @ 2019-03-10 12:05 ` Basile Starynkevitch 0 siblings, 0 replies; 14+ messages in thread From: Basile Starynkevitch @ 2019-03-10 12:05 UTC (permalink / raw) To: David Brown, gcc; +Cc: Joel Sherrill On 3/10/19 12:54 PM, David Brown wrote: > On 10/03/2019 07:11, Basile Starynkevitch wrote: >> >> (I am reading the GCC mailing list in digest mode) >> >> On 3/9/19 10:58 PM, gcc-digest-help@gcc.gnu.org wrote: >> >>> >>> On Fri, 8 Mar 2019, Joel Sherrill wrote: >>> >>>> Can gcc report when the parameter name in a C prototype >>>> does not match that used in the implementation? >>>> >>>> int f(int x); >>>> >>>> int f(int y) {...} >>> I think this would be normal and expected - an installed header >>> would use >>> a reserved-namespace name for the parameter while the implementation >>> uses >>> a non-reserved name that's more convenient for use within the >>> implementation. (Thus anything like this would only be useful if it >>> can >>> know that it's e.g. OK to have __y and y as the names, and some code no >>> doubt uses other such conventions relating the two names.) >>> I can appreciate that a warning like this is not for everyone. But >>> /I/ would like and use such a warning for my own code. >> May I remind to all that this is a typical case for you writing a GCC >> plugin. You want a warning that few other people want, and that >> warning is tied to your particular coding style. >> >> You could avoid that warning by avoid naming the parameters in your >> header files, so you would declare >> int f (int /*x*/); in your header file. >> >> You might want to get a warning, but since it is not of general use >> (as many explained, not using the same name in the header and in the >> implementation of a given function parameter makes a lot of sense in >> general, even if you dislike such as style) you really should >> consider writing your own GCC plugin for that purpose. >> >> How to write such a GCC plugin is a different question, and should be >> asked as such. >> >> Cheers. >> > > I fully agree that this is not a warning everyone will want - but I > disagree with the idea that it is a specialist or unusual warning. > Remember, no one is asking for it to be in -Wall or -Wextra. gcc has > many, many warnings available, and a large proportion of them will > only be useful to a small proportion of users. You could certainly > say that of things like "-Wmissing-prototypes", > "-Wmissing-declarations" and "-Wredundant-decls". I fail to see that > this suggestion is at all different. > > In particular, I see this warning being of little use for large C / > C++ applications with code split into multiple libraries. But I see > it as being of a good deal of use in small-systems embedded > programming where you have a smaller code base, all compiled together > in one project, and where coding conventions and styles are often > strict. That will apply to only a very small proportion of people > programming for x86-64 targets - but a very high proportion of those > programming for AVR, msp430, ARM Cortex-M, and most of the other > targets of gcc. It is easy to forget or underestimate the huge range > of types of programming done with gcc - there are many of us for whom > warnings like this would be a useful tool. > > However, you are right that plugins could be a way to achieve this. I > think the Python plugin could be a good way to prototype features like > this - and if it is useful, then it could be moved into gcc main. > In the long term, the question becomes philosophical. I would be really happy if every future GCC release would come with a small set of "example" plugins for various unusual warnings. And I even think that such an approach will favor outside people to write plugins for their needs. I am not so sure that making an even larger cc1plus binary is wanted. Of course, I am making the hypothesis that plugins are as necessary as directories to host GCC. Cheers -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-03-28 6:07 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-08 22:25 Warning for C Parameter Name Mismatch Joel Sherrill 2019-03-08 23:06 ` Joseph Myers 2019-03-08 23:36 ` David Brown 2019-03-09 2:23 ` Eric Gallager 2019-03-09 8:30 ` Jonathan Wakely 2019-03-09 17:27 ` Segher Boessenkool 2019-03-09 17:51 ` Joel Sherrill 2019-03-11 11:35 ` Jonathan Wakely 2019-03-11 11:26 ` Jonathan Wakely 2019-03-09 12:22 ` David Brown 2019-03-28 6:07 ` Eric Gallager [not found] <1552168709.15796.ezmlm@gcc.gnu.org> 2019-03-10 6:11 ` Basile Starynkevitch 2019-03-10 11:54 ` David Brown 2019-03-10 12:05 ` Basile Starynkevitch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).