Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[G. Branden Robinson via Gcc]

Hi Alex,

At 2022-11-10T01:06:31+0100, Alejandro Colomar wrote:
> Now, I've released man-pages-6.01 very recently (just a few weeks
> ago), and I don't plan to release again in a year or two, so there's
> time to do the implementation in GCC.  From my side, please consider
> this an ACK or even somewhat of a push to get things done in the
> compiler side of things :)

Do you mean you _don't_ plan to release again for a year or two?

You know what Moltke said about plans and contact with the enemy.  For
one thing, I think the Linux kernel will move too fast to permit such a
leisurely cadence.

Also, as soon as Bertrand and I can get groff 1.23 out[1], I am hoping
you will, shortly thereafter, migrate to the new `MR` macro.



Regards,
Branden

[1] Only 6 RC bugs left!


https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&set=custom&report_id=225&status_id=1&plan_release_id=103


signature.asc
Description: PGP signature

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

Hi Joseph and Martin!

On 11/10/22 07:21, Martin Uecker wrote:

Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers:

On Thu, 10 Nov 2022, Joseph Myers wrote:


On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:


I've shown the three kinds of prototypes that have been changed:

-  Normal VLA; nothing fancy except for the '.'.
-  Complex size expressions.
-  'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).


That doesn't cover any of the tricky issues with such proposals, such as
the choice of which entity is referred to by the parameter name when there
are multiple nested parameter lists that use the same parameter name, or
when the identifier is visible from an outer scope (including in
particular the case where it's declared as a typedef name in an outer
scope).


In fact I can't tell from these examples whether you mean for a '.' token
after '[' to have special semantics, or whether you mean to have a special
'. identifier' form of expression valid in certain context (each of which
introduces its own complications; for the former, typedef names from outer
scopes are problematic; for the latter, it's designated initializers where
you get complications, for example).  Designing new syntax that doesn't
cause ambiguity is generally tricky, and this sort of language extension
is the kind of thing where you'd expect to so through at least five
iterations of a WG14 paper before you have something like a sound
specification.


I am not sure what Alejandro has in mind exactly, but my idea of using
a new notation [.identifier] would be to limit it to accessing other
parameter names in the same parameter list only, so that there is

1) no ambiguity what is referred to  and
2) one can access parameters which come later


Yes, I implemented your idea.  As always, I thought I had linked to it in the 
commit message, but I didn't.  Quite a bad thing for the commit that implements 
a completely new feature to not point to the documentation/idea at all.


So, the documentation followed by these 3 patches is Martin's email:


It was sound in my head, and I couldn't see any inconsistencies.

-  I implemented it with '.' as being restricted to refer to parameters of the 
function being prototypes (commit 1).


-  I also allowed complex expressions in the prototypes (commit 2), since it's 
something that can be quite useful (that was already foreseen by Martin's idea, 
IIRC).  The most useful example that I have in my mind is a patch that I'm 
developing for shadow-utils:




   The gist of it is a function that gets a fixed-width non-NUL-terminated 
string, and copies it into a NUL-terminated string in a buffer than has to be of 
course +1 the size of the input string:


void buf2str(char dst[restrict .n+1], const char src[restrict .n],
 size_t n);

-  I extended the idea to apply to void[] (commit 3).  Something not yet allowed 
by GCC, but very useful IMO, especially for the mem...(3) functions.  Since GNU 
C consistently treats sizeof(void)==1, it makes sense to allow VLA syntax in 
that way.  This is not at all about allowing true VLAs of type void[]; that's 
forbidden, and should continue to be forbidden.  But since parameters are just 
pointers, I don't see any issue with allowing false void[] VLAs in parameters 
that really are void* in disguise.



The 3 commits are here (last 3 commits in that log):



Martin, please check if I implemented your idea faithfully.  The 3 example 
prototypes I showed are good representatives of what I added, so if you don't 
understand man(7) source you could just read them and see if they make sense to 
you; the rest of the changes are of the same kind.  Or you could install the man 
pages from the repo :)






If we want to specify something like this, I think we should also
restrict what kind of expressions one allows, e.g. it has to
be side-effect free.


Well, yes, there should be no side effects; it would not make sense in a 
prototype.  I'd put it as simply as with _Generic(3) and similar stuff, where 
the controlling expression is not evaluated for side effects.  I never remember 
about sizeof() or typeof(): I always need to consult if they have side effects 
or not.  I'll be documenting that in the man-pages soon.



 But maybe we want to make this even more
restrictive (at least initially).


Yeah, you could go for an initial implementation that only supports my commit 1; 
that would be the simplest.  That would cover already the vast majority of 
cases.  But please consider commits 2 and 3 afterwards, since I believe they are 
also of great importance.




One p

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

Hi Branden!

On 11/10/22 10:40, G. Branden Robinson wrote:

Hi Alex,

At 2022-11-10T01:06:31+0100, Alejandro Colomar wrote:

Now, I've released man-pages-6.01 very recently (just a few weeks
ago), and I don't plan to release again in a year or two, so there's
time to do the implementation in GCC.  From my side, please consider
this an ACK or even somewhat of a push to get things done in the
compiler side of things :)


Do you mean you _don't_ plan to release again for a year or two?

You know what Moltke said about plans and contact with the enemy.  For
one thing, I think the Linux kernel will move too fast to permit such a
leisurely cadence.


Heh, at this point, I burnt my ships, by using enhanced VLA syntax.  If I 
release that before GCC, I'm expecting to see an avalanche of reports about it 
(and I also expect that GCC and forums will receive a similar ammount).  So yes, 
I expect to wait some longish time.




Also, as soon as Bertrand and I can get groff 1.23 out[1], I am hoping
you will, shortly thereafter, migrate to the new `MR` macro.


Not as soon as it gets released, because I expect (at least a decent amount of) 
contributors to be able to read the pages to which they contribute to, but as 
soon as it makes it into Debian stable, yes, that's in my plans.  So, if you 
make it before the freeze, that means around a couple of months from now.











Regards,
Branden

[1] Only 6 RC bugs left!


Looks good!

Cheers,

Alex



 
https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&set=custom&report_id=225&status_id=1&plan_release_id=103


--



OpenPGP_signature
Description: OpenPGP digital signature

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 11/9/22 18:14, Joseph Myers wrote:

On Wed, 9 Nov 2022, Martin Liška wrote:


1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am.
Apparently, I modified the generated Makefile.in file with the rules like:

doc/info/texinfo/libitm.info: $(SPHINX_FILES)
+ if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
  make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
else true; fi

Can you please modify Makefile.am in the corresponding manner and re-generate 
Makefile.in?


I think someone else had best look at this.


All right, I've got a patch candidate for it, so I'll be hopefully able to 
manage.




2) Adding proper support --enable-generated-files-in-srcdir in gcc_release:


It looks like all the GENINSRC rules / conditionals are still present.
So maybe there are details where the paths are wrong, or where fixes are
needed to ensure the files get installed from the source directory when
available in the source directory but not available in the build directory
because Sphinx isn't available, but much of the code for the feature is
still there.


I can investigate then. Is the option --enable-generated-files-in-srcdir suppose
to be used when building from a release tarball (that includes man/info in src),
or to create such a source tarball?

Cheers,
Martin

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Richard Biener via Gcc]

On Thu, Nov 10, 2022 at 2:05 PM Martin Liška  wrote:
>
> On 11/9/22 18:14, Joseph Myers wrote:
> > On Wed, 9 Nov 2022, Martin Liška wrote:
> >
> >> 1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am.
> >> Apparently, I modified the generated Makefile.in file with the rules like:
> >>
> >> doc/info/texinfo/libitm.info: $(SPHINX_FILES)
> >>  + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
> >>make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
> >> BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
> >>  else true; fi
> >>
> >> Can you please modify Makefile.am in the corresponding manner and 
> >> re-generate Makefile.in?
> >
> > I think someone else had best look at this.
>
> All right, I've got a patch candidate for it, so I'll be hopefully able to 
> manage.
>
> >
> >> 2) Adding proper support --enable-generated-files-in-srcdir in gcc_release:
> >
> > It looks like all the GENINSRC rules / conditionals are still present.
> > So maybe there are details where the paths are wrong, or where fixes are
> > needed to ensure the files get installed from the source directory when
> > available in the source directory but not available in the build directory
> > because Sphinx isn't available, but much of the code for the feature is
> > still there.
>
> I can investigate then. Is the option --enable-generated-files-in-srcdir 
> suppose
> to be used when building from a release tarball (that includes man/info in 
> src),
> or to create such a source tarball?

It's to create such a tarball which then can be built with a reduced toolset.

> Cheers,
> Martin
>

Links to web pages are broken.

[Georg-Johann Lay]

Hi, I just observed that links like

https://gcc.gnu.org/install/configure.html

ceased to work.  Presumably this is to sphinx stuff, but it would be 
great if not hundreds of links across the web to GCC pages like the 
above would be 404.


I know that the new link is

https://gcc.gnu.org/install/configuration.html

but that doesn't help with existing pointers.

"Deep" links like https://gcc.gnu.org/install/configuration.html#avr

won't work either, so all reasonable anchors have been ditched, too?

Johann

Re: Links to web pages are broken.

[Martin Liška]

On 11/10/22 15:45, Georg-Johann Lay wrote:

Hi, I just observed that links like

https://gcc.gnu.org/install/configure.html

ceased to work.  Presumably this is to sphinx stuff, but it would be great if 
not hundreds of links across the web to GCC pages like the above would be 404.

I know that the new link is

https://gcc.gnu.org/install/configuration.html

but that doesn't help with existing pointers.

"Deep" links like https://gcc.gnu.org/install/configuration.html#avr

won't work either, so all reasonable anchors have been ditched, too?

Johann


Hello.

We're working on that and we'll create a redirection:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610

Thanks for pointing out.

Martin

Re: Links to web pages are broken.

[Georg-Johann Lay]

Am 10.11.22 um 16:05 schrieb Martin Liška:

On 11/10/22 15:45, Georg-Johann Lay wrote:

Hi, I just observed that links like

https://gcc.gnu.org/install/configure.html

ceased to work.  Presumably this is to sphinx stuff, but it would be 
great if not hundreds of links across the web to GCC pages like the 
above would be 404.


I know that the new link is

https://gcc.gnu.org/install/configuration.html

but that doesn't help with existing pointers.

"Deep" links like https://gcc.gnu.org/install/configuration.html#avr

won't work either, so all reasonable anchors have been ditched, too?

Johann


Hello.

We're working on that and we'll create a redirection:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610

Thanks for pointing out.

Martin


Ok thanks, I left a note there.

Johann

Re: Links to web pages are broken.

[Jonathan Wakely via Gcc]

On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay  wrote:
>
>
>
> Am 10.11.22 um 16:05 schrieb Martin Liška:
> > On 11/10/22 15:45, Georg-Johann Lay wrote:
> >> Hi, I just observed that links like
> >>
> >> https://gcc.gnu.org/install/configure.html
> >>
> >> ceased to work.  Presumably this is to sphinx stuff, but it would be
> >> great if not hundreds of links across the web to GCC pages like the
> >> above would be 404.
> >>
> >> I know that the new link is
> >>
> >> https://gcc.gnu.org/install/configuration.html
> >>
> >> but that doesn't help with existing pointers.
> >>
> >> "Deep" links like https://gcc.gnu.org/install/configuration.html#avr
> >>
> >> won't work either, so all reasonable anchors have been ditched, too?
> >>
> >> Johann
> >
> > Hello.
> >
> > We're working on that and we'll create a redirection:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610
> >
> > Thanks for pointing out.
> >
> > Martin
>
> Ok thanks, I left a note there.

The second part of your note about deep links into the new docs is a
completely separate issue. That can't be fixed with HTTP redirects for
the old URLs.

Re: Links to web pages are broken.

[Jonathan Wakely via Gcc]

On Thu, 10 Nov 2022 at 15:23, Jonathan Wakely  wrote:
>
> On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay  wrote:
> >
> >
> >
> > Am 10.11.22 um 16:05 schrieb Martin Liška:
> > > On 11/10/22 15:45, Georg-Johann Lay wrote:
> > >> Hi, I just observed that links like
> > >>
> > >> https://gcc.gnu.org/install/configure.html
> > >>
> > >> ceased to work.  Presumably this is to sphinx stuff, but it would be
> > >> great if not hundreds of links across the web to GCC pages like the
> > >> above would be 404.
> > >>
> > >> I know that the new link is
> > >>
> > >> https://gcc.gnu.org/install/configuration.html
> > >>
> > >> but that doesn't help with existing pointers.
> > >>
> > >> "Deep" links like https://gcc.gnu.org/install/configuration.html#avr
> > >>
> > >> won't work either, so all reasonable anchors have been ditched, too?
> > >>
> > >> Johann
> > >
> > > Hello.
> > >
> > > We're working on that and we'll create a redirection:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610
> > >
> > > Thanks for pointing out.
> > >
> > > Martin
> >
> > Ok thanks, I left a note there.
>
> The second part of your note about deep links into the new docs is a
> completely separate issue. That can't be fixed with HTTP redirects for
> the old URLs.

And there are still anchors, they're just different:
https://gcc.gnu.org/install/configuration.html#cmdoption-with-avrlibc
Now there are anchors to every single option, which is much better
than it used to be.

Re: Links to web pages are broken.

[Georg-Johann Lay]

Am 10.11.22 um 16:25 schrieb Jonathan Wakely:

On Thu, 10 Nov 2022 at 15:23, Jonathan Wakely  wrote:


On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay  wrote:




Am 10.11.22 um 16:05 schrieb Martin Liška:

On 11/10/22 15:45, Georg-Johann Lay wrote:

Hi, I just observed that links like

https://gcc.gnu.org/install/configure.html

ceased to work.  Presumably this is to sphinx stuff, but it would be
great if not hundreds of links across the web to GCC pages like the
above would be 404.

I know that the new link is

https://gcc.gnu.org/install/configuration.html

but that doesn't help with existing pointers.

"Deep" links like https://gcc.gnu.org/install/configuration.html#avr

won't work either, so all reasonable anchors have been ditched, too?

Johann


Hello.

We're working on that and we'll create a redirection:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610

Thanks for pointing out.

Martin


Ok thanks, I left a note there.


The second part of your note about deep links into the new docs is a
completely separate issue. That can't be fixed with HTTP redirects for
the old URLs.


And there are still anchors, they're just different:
https://gcc.gnu.org/install/configuration.html#cmdoption-with-avrlibc
Now there are anchors to every single option, which is much better
than it used to be.


Yes, its nice.  But existing links are still invalidated.  Just take 
some tutorial that explains how to set up gcc, where you want to provide 
references that are point-on and not just "gcc.gnu.org".


Does this also mean that "deep" links to onlinedocs won't work any more?

Johann

Re: Links to web pages are broken.

[Richard Biener via Gcc]

> Am 10.11.2022 um 17:45 schrieb Georg-Johann Lay :
> 
> 
> 
>> Am 10.11.22 um 16:25 schrieb Jonathan Wakely:
>>> On Thu, 10 Nov 2022 at 15:23, Jonathan Wakely  wrote:
>>> 
>>> On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay  wrote:
 
 
 
 Am 10.11.22 um 16:05 schrieb Martin Liška:
> On 11/10/22 15:45, Georg-Johann Lay wrote:
>> Hi, I just observed that links like
>> 
>> https://gcc.gnu.org/install/configure.html
>> 
>> ceased to work.  Presumably this is to sphinx stuff, but it would be
>> great if not hundreds of links across the web to GCC pages like the
>> above would be 404.
>> 
>> I know that the new link is
>> 
>> https://gcc.gnu.org/install/configuration.html
>> 
>> but that doesn't help with existing pointers.
>> 
>> "Deep" links like https://gcc.gnu.org/install/configuration.html#avr
>> 
>> won't work either, so all reasonable anchors have been ditched, too?
>> 
>> Johann
> 
> Hello.
> 
> We're working on that and we'll create a redirection:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610
> 
> Thanks for pointing out.
> 
> Martin
 
 Ok thanks, I left a note there.
>>> 
>>> The second part of your note about deep links into the new docs is a
>>> completely separate issue. That can't be fixed with HTTP redirects for
>>> the old URLs.
>> And there are still anchors, they're just different:
>> https://gcc.gnu.org/install/configuration.html#cmdoption-with-avrlibc
>> Now there are anchors to every single option, which is much better
>> than it used to be.
> 
> Yes, its nice.  But existing links are still invalidated.  Just take some 
> tutorial that explains how to set up gcc, where you want to provide 
> references that are point-on and not just "gcc.gnu.org".
> 
> Does this also mean that "deep" links to onlinedocs won't work any more?

How about moving the new docs to
onlinedocs-new/ and simply keeping the old
Doc tree around?  Re-using the old dir looks like a mistake in hindsight?

Richard 

> Johann
> 
> 

Re: Links to web pages are broken.

[Jonathan Wakely via Gcc]

On Thu, 10 Nov 2022 at 16:58, Richard Biener  wrote:
>
>
>
> > Am 10.11.2022 um 17:45 schrieb Georg-Johann Lay :
> >
> > 
> >
> >> Am 10.11.22 um 16:25 schrieb Jonathan Wakely:
> >>> On Thu, 10 Nov 2022 at 15:23, Jonathan Wakely  wrote:
> >>>
> >>> On Thu, 10 Nov 2022 at 15:17, Georg-Johann Lay  wrote:
> 
> 
> 
>  Am 10.11.22 um 16:05 schrieb Martin Liška:
> > On 11/10/22 15:45, Georg-Johann Lay wrote:
> >> Hi, I just observed that links like
> >>
> >> https://gcc.gnu.org/install/configure.html
> >>
> >> ceased to work.  Presumably this is to sphinx stuff, but it would be
> >> great if not hundreds of links across the web to GCC pages like the
> >> above would be 404.
> >>
> >> I know that the new link is
> >>
> >> https://gcc.gnu.org/install/configuration.html
> >>
> >> but that doesn't help with existing pointers.
> >>
> >> "Deep" links like https://gcc.gnu.org/install/configuration.html#avr
> >>
> >> won't work either, so all reasonable anchors have been ditched, too?
> >>
> >> Johann
> >
> > Hello.
> >
> > We're working on that and we'll create a redirection:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107610
> >
> > Thanks for pointing out.
> >
> > Martin
> 
>  Ok thanks, I left a note there.
> >>>
> >>> The second part of your note about deep links into the new docs is a
> >>> completely separate issue. That can't be fixed with HTTP redirects for
> >>> the old URLs.
> >> And there are still anchors, they're just different:
> >> https://gcc.gnu.org/install/configuration.html#cmdoption-with-avrlibc
> >> Now there are anchors to every single option, which is much better
> >> than it used to be.
> >
> > Yes, its nice.  But existing links are still invalidated.  Just take some 
> > tutorial that explains how to set up gcc, where you want to provide 
> > references that are point-on and not just "gcc.gnu.org".
> >
> > Does this also mean that "deep" links to onlinedocs won't work any more?
>
> How about moving the new docs to
> onlinedocs-new/ and simply keeping the old
> Doc tree around?  Re-using the old dir looks like a mistake in hindsight?

Maybe just "docs" or "trunkdocs" or "latestdocs" instead of
"onlinedocs-new", since that is (1) very long, and (2) will look silly
in ten years when it's not new and we need to add
onlinedocs-even-newer ;-)

Or even onlinedocs/latest/ for the new stuff, and leave the old stuff
there in onlinedocs/ (without linking to it) so that old links work.

How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg via Gcc]

I’m the closest thing Autoconf has to a lead maintainer at present.

It’s come to my attention (via https://lwn.net/Articles/913505/ and
https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
Clang both plan to disable several “legacy” C language features by
default in a near-future release (GCC 14, Clang 16) (see the Fedora
wiki link for a list).  I understand that this change potentially
breaks a lot of old dusty code, and in particular that
Autoconf-generated configure scripts use constructs that may *silently
give the wrong answer to a probe* when a stricter compiler is in use.

Nobody has a whole lot of time to work on Autoconf at present, but I
would like to ask, anyway, what Autoconf could potentially do to make
this transition easier.  I’m already aware that the test code Autoconf
2.71 uses to probe for C89/C99/C11 support is broken; this has been
fixed in development trunk to the extent it is possible for me to test
it with GCC 12 (commit:
).
Several other places using K&R function definitions and/or
unprototyped function declarations (including the ubiquitously used
AC_CHECK_FUNC) have also been fixed on trunk,
.
Changes to handle C23 built-in ‘bool’ better are under development but
the design has not yet been finalized.

The biggest remaining (potential) problem, that I’m aware of, is that
AC_CHECK_FUNC unconditionally declares the function we’re probing for
as ‘char NAME (void)’, and asks the compiler to call it with no
arguments, regardless of what its prototype actually is.  It is not
clear to me whether this will still work with the planned changes to
the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
triggered by ‘extern char memcpy(void);’ (or any other standard
library function whose prototype is coded into the compiler) and this
already causes problems for people who run configure scripts with
CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
have to build a comprehensive list of library functions into Autoconf,
mapping each to either its documented prototype or to a header where
it ought to be declared; in the latter case we would also have to make
e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
sys/socket.h netdb.h]) which might mess up configure scripts that
aren’t expecting headers to be probed at that point.

How important do you think it is for this to be fixed?

Are there any other changes you would like to see in a near-future
Autoconf 2.72 in order to make this transition easier?

zw

p.s. GCC and Clang folks: As long as you’re changing the defaults out
from under people, can you please also remove the last few predefined
user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
-std=gnuXX modes?

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Nick Bowler]

On 2022-11-10, Zack Weinberg  wrote:
> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.
>
> How important do you think it is for this to be fixed?

My gut feeling is that Autoconf should just determine the necessary
options to get compatible behaviour out of these modern compilers, at
least for the purpose of running configure tests.  For example, Autoconf
should probably build the AC_CHECK_FUNC programs using gcc's
-fno-builtin option, which should avoid problems with gcc complaining
about memcpy (and may also improve test accuracy, since gcc won't use
its knowledge of C library behaviour to possibly elide the call to
memcpy).

It saddens me to see so much breakage happening in "modern C", a
language that has (until now) a long history of new language features
being carefully introduced to avoid these sort of problems.

The fact that even the C standard authors don't even seem to care about
existing codebases is a concerning change in direction.  Nobody has
learned anything from the Python 3 debacle, I guess.

> p.s. GCC and Clang folks: As long as you’re changing the defaults out
> from under people, can you please also remove the last few predefined
> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
> -std=gnuXX modes?

Meh, even though these macros are a small thing I don't accept the
"things are breaking anyway so let's break even more things" attitude.
This was something that many library authors did during the python 3
transition and that just made the problems orders of magnitude more
horrible.

Cheers,
  Nick

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Jonathan Wakely via Gcc]

On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> It saddens me to see so much breakage happening in "modern C", a
> language that has (until now) a long history of new language features
> being carefully introduced to avoid these sort of problems.

The features were introduced in 1999. Compilers just continued to
accept broken code, because people seem to think accepting garbage
forever is "compatibility".

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Rich Felker]

On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
> I’m the closest thing Autoconf has to a lead maintainer at present.
> 
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language features by
> default in a near-future release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.
> 
> Nobody has a whole lot of time to work on Autoconf at present, but I
> would like to ask, anyway, what Autoconf could potentially do to make
> this transition easier.  I’m already aware that the test code Autoconf
> 2.71 uses to probe for C89/C99/C11 support is broken; this has been
> fixed in development trunk to the extent it is possible for me to test
> it with GCC 12 (commit:
> ).
> Several other places using K&R function definitions and/or
> unprototyped function declarations (including the ubiquitously used
> AC_CHECK_FUNC) have also been fixed on trunk,
> .
> Changes to handle C23 built-in ‘bool’ better are under development but
> the design has not yet been finalized.
> 
> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.
> 
> How important do you think it is for this to be fixed?
> 
> Are there any other changes you would like to see in a near-future
> Autoconf 2.72 in order to make this transition easier?

Thanks for bringing this up. It is very important and I am very much
in favor of making these changes and doing it in a way that existing
broken and unmaintained software can be made to work just by
re-generating configure scripts with up-to-date autoconf, even if that
means hard-coding a list of headers needed to get the right
declarations and automatically pulling them in. Otherwise this is
going to be a gigantic burden on distro maintainers/systems
integrators.

I've been writing/complaining about autoconf doing this wrong for
decades, with the best writeup around 9 years ago at
https://ewontfix.com/13/. Part of the reason is that this has bitten
musl libc users over and over again due to configure finding symbols
that were intended only as ABI-compat and trying to use them (without
declarations) at the source level, leading to various messes, some of
which we're only just extricating ourselves from now:

https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4
https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc

But aside from issues like this, just the fact that autoconf was
precluding making -Werror=implicit-function-declaration default must
have wasted tens if not hundreds of thousands of human hours debugging
broken builds.

What I'd like to see happen is complete deprecation of the autoconf
link-only tests -- only keeping them for use by legacy unmaintained
projects in the form where they actually implicitly include the right
header and test compile and link using that.

Rich

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via Gcc]

* Zack Weinberg via Gcc:

> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language features by
> default in a near-future release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.

Thank you for reaching out.  The c-std-porting list isn't even
bootstrapped yet, the Fedora documentation is still in flux, and the
Fedora oversight body just approved working on this in the Fedora
context.  That LWN article caught me a bit off guard.

Anyway, based on a limited attempt to get this fixed about three years
ago, I expect that many of the problematic packages have not had their
configure scripts regenerated using autoconf for a decade or more.  This
means that as an autoconf maintainer, you unfortunately won't be able to
help us much.

> Nobody has a whole lot of time to work on Autoconf at present, but I
> would like to ask, anyway, what Autoconf could potentially do to make
> this transition easier.  I’m already aware that the test code Autoconf
> 2.71 uses to probe for C89/C99/C11 support is broken; this has been
> fixed in development trunk to the extent it is possible for me to test
> it with GCC 12 (commit:
> ).

Thanks, these changes are going to be helpful to get a clean run from
our Fedora tester.

I also noticed some issues in the automake test suite, and I hope
Frederic can have a look at them:

  automake: Port to modern C
  

> Several other places using K&R function definitions and/or
> unprototyped function declarations (including the ubiquitously used
> AC_CHECK_FUNC) have also been fixed on trunk,
> .

One reason I hesitate to recommend wide testing with -Werror=… is that
it is actually impossible to model future GCC behavior with -Werror=…
options today.  I very much doubt that the AC_CHECK_FUNC change [that
is, () → (void)] will ever be required by real GCC.  I'm worried that
some of this -Werror=… testing merely introduces unnecessary churn.
These changes help maintainers who wnat to build their packages with
CC="gcc -Werror=…" or something like that, so I guess they still make
sense for autoconf.  But perhaps not as a general model for everyone
else.

> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.

I think t his approach is actually the most portable approach, at least
as far as GCC is concerned.  GCC treats a function as a compiler
built-in only if the declared prototype matches its expectations.  I
doubt there are any such functions returning char, which makes this
declaration a good choice.  I do not expect any medium-term changes to
the situation here.  The warning will stay, it will not turn into an
error.

> Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.

Once you include the header, you also need to know function parameters,
otherwise you won't be able to form a valid call.  Python
setuptools/distutils tried to do something along this lines, but I can't
see how it can work, as explained here:

  Unclear how CCompiler.has_function works for functions with parameters
  

The char-returning prototype does not seem so bad in the end.  The
function is actually called and the result returned from main, so it's
even compatible with LTO.

> How important do you think it is for this to be fixed?

In isolation?  Not important at all.  Maybe it wo

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Jonathan Wakely via Gcc]

On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote:
>
> On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> > It saddens me to see so much breakage happening in "modern C", a
> > language that has (until now) a long history of new language features
> > being carefully introduced to avoid these sort of problems.
>
> The features were introduced in 1999.

Well, some of them were. Some more are coming now in C2x but the
problem has existed since C99 it's just that compilers "protected"
most users from having to fix their code at the time. But it's been
more than two decades and it's time to accept that missing prototypes,
implicit conversions between pointers and ints etc are a hazard and
should be diagnosed not ignored for the benefit of people who never
want to fix their questionable code.

> Compilers just continued to
> accept broken code, because people seem to think accepting garbage
> forever is "compatibility".

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman via Gcc]

On Thu, Nov 10, 2022 at 12:16 PM Zack Weinberg via cfe-commits
 wrote:
>
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language features by
> default in a near-future release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.
>
> Nobody has a whole lot of time to work on Autoconf at present, but I
> would like to ask, anyway, what Autoconf could potentially do to make
> this transition easier.  I’m already aware that the test code Autoconf
> 2.71 uses to probe for C89/C99/C11 support is broken; this has been
> fixed in development trunk to the extent it is possible for me to test
> it with GCC 12 (commit:
> ).
> Several other places using K&R function definitions and/or
> unprototyped function declarations (including the ubiquitously used
> AC_CHECK_FUNC) have also been fixed on trunk,
> .
> Changes to handle C23 built-in ‘bool’ better are under development but
> the design has not yet been finalized.

Thank you for all of your efforts in modernizing autoconf in response
to all these changes, it's greatly appreciated!

> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.

In terms of the Clang side of things, I don't think we've formed any
sort of official stance on how to handle that yet. It's UB (you can
declare the C standard library interface without UB but calling any
function with a mismatched signature is UB) and that UB has some
amount of security implications associated with it, so I would say
there's a potential we might want to upgrade the diagnostic severity,
but it's not assured. FWIW, we're working on improving communication
about potentially disruptive changes to Clang, so you might want to
consider either subscribing to the clang-vendors code review group at
https://reviews.llvm.org/project/members/113/ (if you want to be
involved in code review before things land) or the Announcements
discourse channel at https://discourse.llvm.org/c/announce/ (if you
want to be notified after something lands but before Clang ships).

> How important do you think it is for this to be fixed?
>
> Are there any other changes you would like to see in a near-future
> Autoconf 2.72 in order to make this transition easier?

I don't have a specific list, but as a general request: moving away
from deprecated facilities of C or reliance on UB is a very pragmatic
idea given that the C committee is recapturing some of that design
space (like what happened with K&R C signatures) and implementers are
trying to improve the security posture for C.

> zw
>
> p.s. GCC and Clang folks: As long as you’re changing the defaults out
> from under people, can you please also remove the last few predefined
> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
> -std=gnuXX modes?

If we can do so without breaking the world, I personally think it
would be nice to remove them.

~Aaron

> ___
> cfe-commits mailing list
> cfe-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

-Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

[Florian Weimer via Gcc]

GCC accepts various conversions between pointers and ints and different
types of pointers by default, issuing a warning.

I've been reading the (hopefully) relevant partso f the C99 standard,
and it seems to me that C implementations are actually required to
diagnose errors in these cases because they are constraint violations:
the types are not compatible.

Is this interpretation correct?

Sorry if this questions this is more appropriate for the gcc-help list.

Thanks,
Florian

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

[Marek Polacek via Gcc]

On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote:
> GCC accepts various conversions between pointers and ints and different
> types of pointers by default, issuing a warning.
> 
> I've been reading the (hopefully) relevant partso f the C99 standard,
> and it seems to me that C implementations are actually required to
> diagnose errors in these cases because they are constraint violations:
> the types are not compatible.

It doesn't need to be a hard error, a warning is a diagnostic message, which
is enough to diagnose a violation of any syntax rule or constraint.

IIRC, the only case where the compiler _must_ emit a hard error is for #error.
 
> Is this interpretation correct?
> 
> Sorry if this questions this is more appropriate for the gcc-help list.
> 
> Thanks,
> Florian
> 

Marek

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman via Gcc]

On Thu, Nov 10, 2022 at 1:12 PM Jonathan Wakely via cfe-commits
 wrote:
>
> On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote:
> >
> > On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> > > It saddens me to see so much breakage happening in "modern C", a
> > > language that has (until now) a long history of new language features
> > > being carefully introduced to avoid these sort of problems.
> >
> > The features were introduced in 1999.
>
> Well, some of them were. Some more are coming now in C2x but the
> problem has existed since C99 it's just that compilers "protected"
> most users from having to fix their code at the time. But it's been
> more than two decades and it's time to accept that missing prototypes,
> implicit conversions between pointers and ints etc are a hazard and
> should be diagnosed not ignored for the benefit of people who never
> want to fix their questionable code.

Functions without prototypes were deprecated in ANSI C and came into
ISO C as deprecated. They were obsoleted with the release of the 2nd
edition of K&R C (circa 1978) when prototypes were introduced, IIRC.
They've literally never been a recommended practice in standard C.
Implicit function declarations and implicit int were outright removed
from C99 without a deprecation period due to the security concerns
they caused.

~Aaron

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

[Florian Weimer via Gcc]

* Marek Polacek:

> On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote:
>> GCC accepts various conversions between pointers and ints and different
>> types of pointers by default, issuing a warning.
>> 
>> I've been reading the (hopefully) relevant partso f the C99 standard,
>> and it seems to me that C implementations are actually required to
>> diagnose errors in these cases because they are constraint violations:
>> the types are not compatible.
>
> It doesn't need to be a hard error, a warning is a diagnostic message,
> which is enough to diagnose a violation of any syntax rule or
> constraint.
>
> IIRC, the only case where the compiler _must_ emit a hard error is for
> #error.

Hmm, you could be right.

The standard says that constraint violations are not undefiend behavior,
but of course it does not define what happens in the presence of a
constraint violation.  So the behavior is undefined by omission.  This
seems to be a contradiction.

I assumed that there was a rule similar to the the rule for #error for
any kind of diagnostic, which would mean that GCC errors are diagnostic
messages in the sense of the standard, but GCC warnings are not.

I wonder how C++ handles this.

Thanks,
Florian

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert]

On 2022-11-10 09:16, Zack Weinberg wrote:

Changes to handle C23 built-in ‘bool’ better are under development but
the design has not yet been finalized.


[I'm cc'ing this to bug-gnulib too.]

To my mind this is the biggest outstanding issue in Autoconf as far as 
C23 goes, as the upgrade path for Autoconf's existing bool support is 
not entirely clear. As Florian mentioned, distros can't assume Autoconf 
upgrades when building other packages; that being said, we should get 
Autoconf's bool support fixed sooner rather than later as bool hassles 
will remain until Autoconf is fixed and these fixes are propagated to 
Autoconf's users.


Here's the main Autoconf issue issue with bool. Traditionally, Autoconf 
supported K&R C, C89, C99, etc. At some point (I'm not sure when), 
Autoconf started requiring C89 or later. Is it now OK for Autoconf to 
require C99 or later, as far as bool is concerned? If so, that'll 
considerably simplify the ongoing maintenance hassle for bool.


Requiring C99-or-later bool is the option that Gnulib has taken. Its 
'stdbool' module and its gl_C_BOOL macro assumes C99 or later, and as 
far as I know no Gnulib-using package is using Gnulib's 'stdbool-c99' 
module which we kept around in case somebody still needed bool to work 
atop a C89 system. (We considered supporting C23 bool atop C89 but it 
was too painful.)


If we follow Gnulib's lead, Autoconf will generate a config.h that does 
"#include " on pre-C23 systems, and this config.h will not 
not work on pre-C99 systems. This of course could in theory break some 
programs, just as compiling them with C23 can break them. But I don't 
see any better option at this point. And besides, what package outside 
of a museum still requires C89 and don't work with C99?

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert]

On 2022-11-10 10:19, Aaron Ballman wrote:

In terms of the Clang side of things, I don't think we've formed any
sort of official stance on how to handle that yet. It's UB (you can
declare the C standard library interface without UB but calling any
function with a mismatched signature is UB)


The Autoconf-generated code is never executed, so this is not a runtime 
issue; it's merely an issue of undefined behavior during translation. A 
problem could occur with a picky compiler or linker that rejects modules 
with mismatched function type declarations. Does Clang do that, or 
require or use such a linker? If not, there's no practical problem here. 
If so, it'd be helpful if Clang continued to support its traditional 
behavior that doesn't reject Autoconf's test cases, and for this to be 
the default.


Autoconf arose because one cannot ask something like "Can I call the 
renameat2 function with its usual signature?" in standard C code and one 
must escape into something like the shell to handle such questions. C23 
and GCC and Clang have added a few features to answer such questions, 
such as __has_include. But these features don't go nearly far enough. 
For example, __has_include tells me only whether the include file 
 exists; it won't tell me whether I can successfully include 
, or whether  will declare the function 'bar', or whether 
'bar' will have a signature compatible with my code's calls to 'bar'.


If I could request a single thing from the C23/GCC/Clang side, I'd ask 
for better facilities to be able to ask such questions within C code, 
without using the shell. Then a good chunk of Autoconf could dry up and 
blow away.


I realize that I'm asking for a lot. For example, a traditional 
implementation cannot answer the renameat2 question without consulting 
the linker. That being said, this ability is essential for modular 
programming at the low level, and if compilers don't provide this 
ability Autoconf will simply have to do the best it can, regardless of 
whether it generates source code that relies on undefined behavior.

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via Gcc]

* Rich Felker:

> I've been writing/complaining about autoconf doing this wrong for
> decades, with the best writeup around 9 years ago at
> https://ewontfix.com/13/. Part of the reason is that this has bitten
> musl libc users over and over again due to configure finding symbols
> that were intended only as ABI-compat and trying to use them (without
> declarations) at the source level, leading to various messes, some of
> which we're only just extricating ourselves from now:
>
> https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4
> https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc

glibc and autoconf use a __stub_ macro handshake to achieve this.  It
allows you declare and define functions and still have the corresponding
autoconf test fail.  This facility does not depend on GNU-style symbol
versioning.

> But aside from issues like this, just the fact that autoconf was
> precluding making -Werror=implicit-function-declaration default must
> have wasted tens if not hundreds of thousands of human hours debugging
> broken builds.
>
> What I'd like to see happen is complete deprecation of the autoconf
> link-only tests -- only keeping them for use by legacy unmaintained
> projects in the form where they actually implicitly include the right
> header and test compile and link using that.

It may be technically the right thing to do, but for tests that check
for more than just symbol presence, we might need something that has a
third failure mode—“cannot tell”—beyond “feature is there” and “feature
is missing”.  With a binary approach, it is just too easy to produce a
broken test that fails for the wrong reasons.  With compile-time
testing, such unexpected failures become more likely.  Maybe something
like “if strerror_r exists, it must be usable like this, or usable like
that, but not neither or both at the same time”.  Doing this properly
probably needs toolchain support (which is more likely to become
generally available in C++ than in C).

Thanks,
Florian

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[G. Branden Robinson via Gcc]

Hi Alex,

At 2022-11-10T11:59:02+0100, Alejandro Colomar wrote:
> > You know what Moltke said about plans and contact with the enemy.
> > For one thing, I think the Linux kernel will move too fast to permit
> > such a leisurely cadence.
> 
> Heh, at this point, I burnt my ships, by using enhanced VLA syntax.
> If I release that before GCC, I'm expecting to see an avalanche of
> reports about it (and I also expect that GCC and forums will receive a
> similar ammount).  So yes, I expect to wait some longish time.

Hah, you rebutted my Moltke with your namesake.  You understand that I'm
obligated to spring a reference to the Battle of Lepanto or something on
you at some point.

> > Also, as soon as Bertrand and I can get groff 1.23 out[1], I am
> > hoping you will, shortly thereafter, migrate to the new `MR` macro.
> 
> Not as soon as it gets released, because I expect (at least a decent
> amount of) contributors to be able to read the pages to which they
> contribute to,

Laggardly adopters can always put this in man.local.

.if !d MR \{\
.  de MR
.IR \\$1 (\\$2)\\$3
.  .
.\}

> but as soon as it makes it into Debian stable, yes, that's in my
> plans.  So, if you make it before the freeze, that means around a
> couple of months from now.

Yes.  It is a major personal goal to get groff 1.23 into Debian
bookworm.

> > 
> 
> 

https://www.youtube.com/watch?v=VhH2egTLohM

Regards,
Branden


signature.asc
Description: PGP signature

gcc-10-20221110 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20221110 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20221110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision db180454d210561a60e4621cdc7814ab5bcd

You'll find:

 gcc-10-20221110.tar.xz   Complete GCC

  SHA256=2a6641408ca656cbbf50879e3626f59f3d24dff5618f159799b49125fdd9fb98
  SHA1=0b124a98af3a69fa760155e37a49a6f4eed19376

Diffs from 10-20221103 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
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: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

[Jonathan Wakely via Gcc]

On Thu, 10 Nov 2022 at 19:17, Florian Weimer via Gcc  wrote:
>
> * Marek Polacek:
>
> > On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote:
> >> GCC accepts various conversions between pointers and ints and different
> >> types of pointers by default, issuing a warning.
> >>
> >> I've been reading the (hopefully) relevant partso f the C99 standard,
> >> and it seems to me that C implementations are actually required to
> >> diagnose errors in these cases because they are constraint violations:
> >> the types are not compatible.
> >
> > It doesn't need to be a hard error, a warning is a diagnostic message,
> > which is enough to diagnose a violation of any syntax rule or
> > constraint.
> >
> > IIRC, the only case where the compiler _must_ emit a hard error is for
> > #error.
>
> Hmm, you could be right.
>
> The standard says that constraint violations are not undefiend behavior,
> but of course it does not define what happens in the presence of a
> constraint violation.  So the behavior is undefined by omission.  This
> seems to be a contradiction.

As long as a diagnostic is issued, the invalid program can be
successfully translated. Presumably the implementation defines what it
means in that case, because it's not a valid C program, so the
standard no longer applies. As you say, that's undefined by omission.


> I assumed that there was a rule similar to the the rule for #error for
> any kind of diagnostic, which would mean that GCC errors are diagnostic
> messages in the sense of the standard, but GCC warnings are not.
>
> I wonder how C++ handles this.

Similarly. We don't have constraint violations, we have "diagnosable
rules", see [intro.compliance.general]. If a program contains a
violation of a diagnosable rule, the implementation must issue a
diagnostic message. What it does after that is up to the
implementation, the program has left the realm of valid C++ code.

It's not exactly easy for a user to know whether a given compiler
warning was issued because of a constraint (or diagnosable rule)
violation, or because e.g. the compiler thinks extra parens or more
consistent indentation would be a good idea. In the former case, the
program has undefined behaviour (strictly speaking, but in practice
the implementation might "define" its behaviour) and in the latter
case it doesn't. -pedantic-errors can help, as that turns the former
class into errors.

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:

> One problem with WG14 papers is that people put in too much,
> because the overhead is so high and the standard is not updated
> very often.  It would be better to build such feature more
> incrementally, which could be done more easily with a compiler
> extension.  One could start supporting just [.x] but not more
> complicated expressions.

Even a compiler extension requires the level of detail of specification 
that you get with a WG14 paper (and the level of work on finding bugs in 
that specification), to avoid the problem we've had before with too many 
features added in GCC 2.x days where a poorly defined feature is "whatever 
the compiler accepts".

If you use .x as the notation but don't limit it to [.x], you have a 
completely new ambiguity between ordinary identifiers and member names

struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);

where it's newly ambiguous whether ".a = 1" is an assignment to the 
expression ".a" or a use of a designated initializer.

(I think that if you add any syntax for this, GNU VLA forward declarations 
are clearly to be preferred to inventing something new like [.x] which 
introduces its own problems.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

Hi Joseph,

On 11/11/22 00:19, Joseph Myers wrote:

On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:


One problem with WG14 papers is that people put in too much,
because the overhead is so high and the standard is not updated
very often.  It would be better to build such feature more
incrementally, which could be done more easily with a compiler
extension.  One could start supporting just [.x] but not more
complicated expressions.


Even a compiler extension requires the level of detail of specification
that you get with a WG14 paper (and the level of work on finding bugs in
that specification), to avoid the problem we've had before with too many
features added in GCC 2.x days where a poorly defined feature is "whatever
the compiler accepts".

If you use .x as the notation but don't limit it to [.x], you have a
completely new ambiguity between ordinary identifiers and member names

struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);

where it's newly ambiguous whether ".a = 1" is an assignment to the
expression ".a" or a use of a designated initializer.

(I think that if you add any syntax for this, GNU VLA forward declarations
are clearly to be preferred to inventing something new like [.x] which
introduces its own problems.)


Yeah, I think limiting it to [.n] initially, and only moving forward, step by 
step, if it's perfectly clear that it's doable seems very reasonable.


Re: GNU VLA fwd decl:

This example is what I'm worried about:

int foo(int a; int b[a], int a);
int foo(int a, int b[a], int o);

Okay, parameters should have more readable names...  But still, it allows for a 
high chance of wtf moments.  However, I can think of a syntax very similar to 
GNU's, that would make it a bit better in terms of readability: not declaring 
the type in the fwd decl:



int foo(a; int b[a], int a);
int foo(int a, int b[a], int o);

Cheers,

Alex


--



OpenPGP_signature
Description: OpenPGP digital signature

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

[Joseph Myers]

On Thu, 10 Nov 2022, Florian Weimer via Gcc wrote:

> I assumed that there was a rule similar to the the rule for #error for
> any kind of diagnostic, which would mean that GCC errors are diagnostic
> messages in the sense of the standard, but GCC warnings are not.

The rule (for C) is that any diagnostic required by the standard should 
either be a warning or a pedwarn (where -pedantic-errors turns the latter 
but not the former into errors).

There are a few cases where -pedantic enables warnings that aren't 
pedwarns because they aren't required by the standard; for example, 
-Wformat -pedantic warnings for use of printf format extensions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Different outputs in Gimple pass dump generated by two different architectures

[Kevin Lee]

Hello GCC,

 While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that
x86-64 and risc-v has a different output for the gimple pass since
r12-4790-g4b3a325f07acebf4
. What
would be causing the difference? Is this intended?
Link  for details. Thank you!

Sincerely,
Kevin

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 10 Nov 2022, at 21:10, Michael Orlitzky  wrote:
> 
> On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>> 
>> Nobody has a whole lot of time to work on Autoconf at present, but I
>> would like to ask, anyway, what Autoconf could potentially do to make
>> this transition easier.
> 
> While everyone else is discussing big ideas, it would be helpful for me
> personally if autoconf just made a release with the latest bugfixes.
> 
> I report these compatibility issues upstream, and it's awkward to have
> to tell the maintainers that they must cherry-pick a git commit,
> rebuild autoconf, and then autoreconf their project before they can
> even even think about exporting CFLAGS="-Werror=..." to build-test
> their project.
> 
> 

Before I dive into the rest of this thread: yes, this is one of
my main thoughts on the matter. Autoconf has a huge network
effect problem and letting the existing fixes start to propagate
would be most helpful.

Like it or not (and I don't like it), various software tries
to jam in -Werror (and sometimes -pedantic-errors, see rsync!) to their
configure scripts which means even prototype issues end up
causing problems.

Note that in autoconf git, we've also got 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
which is going to affect time_t efforts too, but that's
for another thread on libc-alpha at some point
when I want to bring up some issues.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg via Gcc]

On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>> On 10 Nov 2022, at 21:10, Michael Orlitzky  wrote:
>> While everyone else is discussing big ideas, it would be helpful for me
>> personally if autoconf just made a release with the latest bugfixes.
>
> Before I dive into the rest of this thread: yes, this is one of
> my main thoughts on the matter. Autoconf has a huge network
> effect problem and letting the existing fixes start to propagate
> would be most helpful.

It would be relatively easy for me to take a couple hours this weekend and put 
out a 2.72 release with everything that's already in trunk and nothing else.  
Anyone have reasons I _shouldn't_ do that?

> Note that in autoconf git, we've also got 
> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
> which is going to affect time_t efforts too

I have not been following the y2038 work closely.  Is it going to affect things 
in a good way or a bad way??

zw