bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* [g.branden.robinson@gmail.com: macOS 12.6.3 and vasnprintf compilation failure]
@ 2023-02-06  8:29 G. Branden Robinson
  2023-02-07  1:06 ` Bruno Haible
  0 siblings, 1 reply; 11+ messages in thread
From: G. Branden Robinson @ 2023-02-06  8:29 UTC (permalink / raw)
  To: bug-gnulib; +Cc: groff

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

[re-sending to correct mailing list]

----- Forwarded message from "G. Branden Robinson" <g.branden.robinson@gmail.com> -----

Date: Mon, 6 Feb 2023 02:28:10 -0600
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: gnulib@gnu.org
Cc: groff@gnu.org
Subject: macOS 12.6.3 and vasnprintf compilation failure

[please CC groff@ on replies]

Hi folks,

groff recently updated its gnulib submodule[1] and published 1.23.0.rc2;
we're hoping to get a final release out soon.

A problem immediately arose on macOS 12.6.3.  It's our good friend
vasnprintf again.  Logs are available on Savannah[2].

lib/vasnprintf.c:411:16: error: expected parameter declarator
static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
               ^
lib/vasnprintf.c:411:16: error: expected ')'
lib/vasnprintf.c:411:15: note: to match this '('
static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
              ^
lib/vasnprintf.c:411:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
^
lib/vasnprintf.c:415:16: error: expected parameter declarator
static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
               ^
lib/vasnprintf.c:415:16: error: expected ')'
lib/vasnprintf.c:415:15: note: to match this '('
static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
              ^
lib/vasnprintf.c:415:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
^

This appears to be a distinct issue from one in macOS 10.13.

https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00056.html

The above output is followed by 14 further warnings howling about the
deprecation of sprintf, but I see that is also being discussed[3], and I
won't gate the groff release on warnings of that nature.

Outright failures, as seen above, though, are a problem.

Any suggestions?

Regards,
Branden

[1] $ git submodule status
 4e9fcc7b84fcac07a3e5a3cd5f66d1ff320dc8e8 gnulib (v0.1-5805-g4e9fcc7b84)
[2] https://savannah.gnu.org/bugs/?63767
[3] https://lists.gnu.org/archive/html/bug-gnulib/2022-11/msg00132.html



----- End forwarded message -----

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [g.branden.robinson@gmail.com: macOS 12.6.3 and vasnprintf compilation failure]
  2023-02-06  8:29 [g.branden.robinson@gmail.com: macOS 12.6.3 and vasnprintf compilation failure] G. Branden Robinson
@ 2023-02-07  1:06 ` Bruno Haible
  2023-02-07  2:01   ` Bjarni Ingi Gislason
  2023-02-07 13:04   ` Alejandro Colomar
  0 siblings, 2 replies; 11+ messages in thread
From: Bruno Haible @ 2023-02-07  1:06 UTC (permalink / raw)
  To: bug-gnulib; +Cc: groff, G. Branden Robinson

Hi Branden,

> A problem immediately arose on macOS 12.6.3.  It's our good friend
> vasnprintf again.  Logs are available on Savannah[2].
> 
> lib/vasnprintf.c:411:16: error: expected parameter declarator
> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>                ^
> lib/vasnprintf.c:411:16: error: expected ')'
> lib/vasnprintf.c:411:15: note: to match this '('
> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>               ^
> lib/vasnprintf.c:411:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
> ^
> lib/vasnprintf.c:415:16: error: expected parameter declarator
> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>                ^
> lib/vasnprintf.c:415:16: error: expected ')'
> lib/vasnprintf.c:415:15: note: to match this '('
> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>               ^
> lib/vasnprintf.c:415:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
> ^

I can reproduce the issue on a macOS 12.5 machine (gcc104.fsffrance.org —
you can surely get an account there too).

The command
  $ make lib/vasnprintf.o V=1
shows me the compiler command line that failed:
depbase=`echo lib/vasnprintf.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
        cc -DHAVE_CONFIG_H -I. -I.. -I./src/include  -I../src/include -I../lib -I./src/include -I./lib -I/Users/haible/include -Wall  -g -O2 -MT lib/vasnprintf.o -MD -MP -MF $depbase.Tpo -c -o lib/vasnprintf.o ../lib/vasnprintf.c &&\
        mv -f $depbase.Tpo $depbase.Po
...

Take this command, remove the -c and -o options, and instead add -E:

  $ cc -DHAVE_CONFIG_H -I. -I.. -I./src/include  -I../src/include -I../lib -I./src/include -I./lib -I/Users/haible/include -Wall  -g -O2 ../lib/vasnprintf.c -E > i

Since it looks like the 'static_assert' macro is not defined, and it
ought to be defined by <config.h> via <assert.h>, two questions arise:

1) Does <config.h> contain the boilerplate for including <assert.h>?
   config.h is found in src/include/config.h.
   Inspection shows: Yes, it does.

2) Does <assert.h> contain the boilerplate for defining 'static_assert'?
   Here's the problem: There are two assert.h files:
     $(builddir)/lib/assert.h        gnulib generated, contains the #define static_assert
     $(srcdir)/src/include/assert.h  groff-owned

   <assert.h> in the newest ISO C 23 standard is supposed to make
   'static_assert' available. [1]

   The problem is a combination of:

     - The groff-owned $(srcdir)/src/include/assert.h takes precedence
       over the one in $(builddir)/lib — due to the particular order of the
       -I options. This can be seen by looking into the 'i' file.

     - The groff-owned $(srcdir)/src/include/assert.h does not use
       #include_next <assert.h>; this would include the next <assert.h>,
       namely $(builddir)/lib/assert.h.

     - The groff-owned $(srcdir)/src/include/assert.h does not define
       'static_assert' by itself.

   So, to fix things, you need to either
     - change the -I options order, or
     - use #include_next <assert.h> if the compiler supports #include_next,
       otherwise #include <absolute_file_name_of_next_assert.h>, or
     - implement your own logic for defining 'static_assert' in C.

   Note: If you go by the first option, you may still get problems on
   those systems where /usr/include/assert.h defines 'static_assert' and
   thus gnulib's $(builddir)/lib/assert.h is just a wrapper without much
   added value. Namely, the lack of #include_next <assert.h> in groff's
   assert.h will prevent /usr/include/assert.h from being read.

Hope this helps. This is not a complete solution, but you get some ideas.

Bruno

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [g.branden.robinson@gmail.com: macOS 12.6.3 and vasnprintf compilation failure]
  2023-02-07  1:06 ` Bruno Haible
@ 2023-02-07  2:01   ` Bjarni Ingi Gislason
  2023-02-07 13:04   ` Alejandro Colomar
  1 sibling, 0 replies; 11+ messages in thread
From: Bjarni Ingi Gislason @ 2023-02-07  2:01 UTC (permalink / raw)
  To: Bruno Haible; +Cc: bug-gnulib, groff, G. Branden Robinson


See https://savannah.gnu.org/bugs/index.php?63078

  I renamed the file "groff/src/include/assert.h" in my privat branch
of groff to ".../assert.h.original".


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [g.branden.robinson@gmail.com: macOS 12.6.3 and vasnprintf compilation failure]
  2023-02-07  1:06 ` Bruno Haible
  2023-02-07  2:01   ` Bjarni Ingi Gislason
@ 2023-02-07 13:04   ` Alejandro Colomar
  2023-02-07 13:43     ` macOS 12.6.3, static_assert, and vasnprintf compilation failure G. Branden Robinson
  1 sibling, 1 reply; 11+ messages in thread
From: Alejandro Colomar @ 2023-02-07 13:04 UTC (permalink / raw)
  To: Bruno Haible, bug-gnulib; +Cc: groff, G. Branden Robinson


[-- Attachment #1.1: Type: text/plain, Size: 2602 bytes --]

Hi all,

On 2/7/23 02:06, Bruno Haible wrote:
> Hi Branden,
> 
>> A problem immediately arose on macOS 12.6.3.  It's our good friend
>> vasnprintf again.  Logs are available on Savannah[2].
>>
>> lib/vasnprintf.c:411:16: error: expected parameter declarator
>> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>>                 ^
>> lib/vasnprintf.c:411:16: error: expected ')'
>> lib/vasnprintf.c:411:15: note: to match this '('
>> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>>                ^
>> lib/vasnprintf.c:411:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
>> static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_LIMB_BITS);
>> ^
>> lib/vasnprintf.c:415:16: error: expected parameter declarator
>> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>>                 ^
>> lib/vasnprintf.c:415:16: error: expected ')'
>> lib/vasnprintf.c:415:15: note: to match this '('
>> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>>                ^
>> lib/vasnprintf.c:415:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
>> static_assert (sizeof (mp_twolimb_t) * CHAR_BIT == GMP_TWOLIMB_BITS);
>> ^
> 
> I can reproduce the issue on a macOS 12.5 machine (gcc104.fsffrance.org —
> you can surely get an account there too).
> 
> The command
>    $ make lib/vasnprintf.o V=1
> shows me the compiler command line that failed:
> depbase=`echo lib/vasnprintf.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
>          cc -DHAVE_CONFIG_H -I. -I.. -I./src/include  -I../src/include -I../lib -I./src/include -I./lib -I/Users/haible/include -Wall  -g -O2 -MT lib/vasnprintf.o -MD -MP -MF $depbase.Tpo -c -o lib/vasnprintf.o ../lib/vasnprintf.c &&\
>          mv -f $depbase.Tpo $depbase.Po
> ...

I don't know if groff is supposed to be compatible with non-GNU compilers, or if 
it has a dependency to GNU C compilers (GCC, Clang, and maybe others).  If you 
require GNU C, maybe you should use -iquote in some places to clarify that quote 
includes should be one thing and bracket includes come from a different place.

Regardless of that, I took practice of having headers in a root directory with 
the name of the project (.../include/groff/...), so that then you always include 
them as `#include "groff/foo.h"` and there's no possible confussion, even if you 
have to use -I for compatibility with other compilers.

Cheers,

Alex
-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 13:04   ` Alejandro Colomar
@ 2023-02-07 13:43     ` G. Branden Robinson
  2023-02-07 14:03       ` Alejandro Colomar
  2023-02-07 14:13       ` Bruno Haible
  0 siblings, 2 replies; 11+ messages in thread
From: G. Branden Robinson @ 2023-02-07 13:43 UTC (permalink / raw)
  To: Alejandro Colomar; +Cc: bug-gnulib, groff

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

[trimming and recasting subject]

Hi Alex,

At 2023-02-07T14:04:54+0100, Alejandro Colomar wrote:
> I don't know if groff is supposed to be compatible with non-GNU
> compilers, or if it has a dependency to GNU C compilers (GCC, Clang,
> and maybe others).  If you require GNU C, maybe you should use -iquote
> in some places to clarify that quote includes should be one thing and
> bracket includes come from a different place.

I'm dithering on that.  Up until Bruno pointed out how this problem
might require #include_next, I assumed that groff had always been
portable to standardized dialects of C and C++,[1] and I have striven to
maintain that portability to conforming implementations.

> Regardless of that, I took practice of having headers in a root
> directory with the name of the project (.../include/groff/...), so
> that then you always include them as `#include "groff/foo.h"` and
> there's no possible confussion, even if you have to use -I for
> compatibility with other compilers.

Yes, I am facing a portability dilemma.  groff's had an assert.h header
since version 1.01 (1991), but I don't know why.  In 2020 I expanded it
to support C99-style assertions (i.e., assertions that communicate
meaning instead of the nearly useless form from C89).  I am trying to
not require C99 features; we can do without variable-length arrays and
complex numbers.  But as a developer I insist on C99 assertions.

I'll characterize the dilemma in more detail when I reply to Bruno's
helpful and detailed message, and after reading a bit of gnulib
documentation that I suspect I've been neglecting.

Regards,
Branden

[1] This statement is weaker than it seems because much of the C++ in
    groff was written ca. 1990, almost a decade before C++ was first
    standardized.  It seems to mostly be in "Annotated Reference Manual"
    C++.  It defines its own string class and uses the STL almost not at
    all, and the few places it does are thanks to contributors after
    James Clark's retirement.  I've personally been opportunistically
    demoting numerous variables and return types from ints to bools.
    And also annotating numerous zero literals with "/* nullptr */", so
    that it will be easier in the future to migrate to the latter.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 13:43     ` macOS 12.6.3, static_assert, and vasnprintf compilation failure G. Branden Robinson
@ 2023-02-07 14:03       ` Alejandro Colomar
  2023-02-07 14:20         ` Bruno Haible
  2023-02-07 14:13       ` Bruno Haible
  1 sibling, 1 reply; 11+ messages in thread
From: Alejandro Colomar @ 2023-02-07 14:03 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: bug-gnulib, groff


[-- Attachment #1.1: Type: text/plain, Size: 4161 bytes --]

Hi Branden,

On 2/7/23 14:43, G. Branden Robinson wrote:
> [trimming and recasting subject]
> 
> Hi Alex,
> 
> At 2023-02-07T14:04:54+0100, Alejandro Colomar wrote:
>> I don't know if groff is supposed to be compatible with non-GNU
>> compilers, or if it has a dependency to GNU C compilers (GCC, Clang,
>> and maybe others).  If you require GNU C, maybe you should use -iquote
>> in some places to clarify that quote includes should be one thing and
>> bracket includes come from a different place.
> 
> I'm dithering on that.  Up until Bruno pointed out how this problem
> might require #include_next, I assumed that groff had always been
> portable to standardized dialects of C and C++,[1] and I have striven to
> maintain that portability to conforming implementations.

Well, ISO C doesn't mention at all compiler flags.  Only POSIX attempts to do 
that: <https://pubs.opengroup.org/onlinepubs/9699919799/>

POSIX only requires -I, which is why I understand not wanting to require a GNU 
compiler.

The good thing is that you don't need that.  You can get away with using a 
project prefix directory (groff/).

> 
>> Regardless of that, I took practice of having headers in a root
>> directory with the name of the project (.../include/groff/...), so
>> that then you always include them as `#include "groff/foo.h"` and
>> there's no possible confussion, even if you have to use -I for
>> compatibility with other compilers.
> 
> Yes, I am facing a portability dilemma.  groff's had an assert.h header
> since version 1.01 (1991), but I don't know why.

Thus you're relying on Undefined Behavior as per 
<https://port70.net/%7Ensz/c/c11/n1570.html#7.1.2p3>:

"If a file with the same name as one of the above < and > delimited sequences, 
not provided as part of the implementation, is placed in any of the standard 
places that are searched for included source files, the behavior is undefined."

The compiler might recognize that <assert.h> is a standard header and provide 
the definitions for it without actually including the file.

>  In 2020 I expanded it
> to support C99-style assertions (i.e., assertions that communicate
> meaning instead of the nearly useless form from C89).  I am trying to
> not require C99 features; we can do without variable-length arrays and
> complex numbers.  But as a developer I insist on C99 assertions.

And you do well.  C99 is great, even if it has features that one can live 
without.  I don't conceive using C89 as something reasonable today.  I wish 2025 
comes soon, and with it the definitive death of CentOS 7 and Debian 8, which are 
the last reducts of GCC defaulting to gnu89.

> 
> I'll characterize the dilemma in more detail when I reply to Bruno's
> helpful and detailed message, and after reading a bit of gnulib
> documentation that I suspect I've been neglecting.
> 
> Regards,
> Branden
> 
> [1] This statement is weaker than it seems because much of the C++ in
>      groff was written ca. 1990, almost a decade before C++ was first
>      standardized.  It seems to mostly be in "Annotated Reference Manual"
>      C++.  It defines its own string class and uses the STL almost not at
>      all, and the few places it does are thanks to contributors after
>      James Clark's retirement.  I've personally been opportunistically
>      demoting numerous variables and return types from ints to bools.

Most of the C++ you use in groff has been backported to C, including bool and 
static_assert() with one argument.

>      And also annotating numerous zero literals with "/* nullptr */", so
>      that it will be easier in the future to migrate to the latter.

You might as well use NULL, which is safer than 0, and is compatible with C++ 
(compilers might even define it to nullptr).

BTW, C23 will add nullptr.  I managed to convince someone to file a nation body 
comment to shot it down, but it survived.  It seems some vendors don't want to 
define NULL as (void *)0.  :(

Cheers,

Alex


-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 13:43     ` macOS 12.6.3, static_assert, and vasnprintf compilation failure G. Branden Robinson
  2023-02-07 14:03       ` Alejandro Colomar
@ 2023-02-07 14:13       ` Bruno Haible
  2023-02-07 14:20         ` Alejandro Colomar
  2023-02-10  0:50         ` G. Branden Robinson
  1 sibling, 2 replies; 11+ messages in thread
From: Bruno Haible @ 2023-02-07 14:13 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: Alejandro Colomar, bug-gnulib, groff

G. Branden Robinson wrote:
> groff's had an assert.h header
> since version 1.01 (1991), but I don't know why.  In 2020 I expanded it
> to support C99-style assertions (i.e., assertions that communicate
> meaning instead of the nearly useless form from C89).  I am trying to
> not require C99 features; we can do without variable-length arrays and
> complex numbers.  But as a developer I insist on C99 assertions.

The Gnulib manual [1] explains that Gnulib essentially assumes C99
already. I still have access to a machine with a pre-C99 compiler,
but I don't use it for testing any more, since there's no point in
using a 20-years old compiler that would barf on 50% of the source
files.

We haven't tested the behaviour of <assert.h> in detail, but you're
*very* likely to get the C99 assertions that you want everywhere.

> might require #include_next

Note that #include_next requires GCC or clang. So it is much more
of a portability constraint than merely requiring C99 or newer.

Therefore:
  - How about removing groff's src/include/assert.h and just rely
    on the one from the system?
  - If that does not work out, how about putting the src/include/assert.h
    into a different directory and adjust the -I options, so that
    the Gnulib compilation units will not see it? Only the groff C++ code
    would see it.

Bruno

[1] <https://www.gnu.org/software/gnulib/manual/html_node/Portability-guidelines.html>





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 14:13       ` Bruno Haible
@ 2023-02-07 14:20         ` Alejandro Colomar
  2023-02-10  0:50         ` G. Branden Robinson
  1 sibling, 0 replies; 11+ messages in thread
From: Alejandro Colomar @ 2023-02-07 14:20 UTC (permalink / raw)
  To: Bruno Haible, G. Branden Robinson; +Cc: bug-gnulib, groff


[-- Attachment #1.1: Type: text/plain, Size: 2208 bytes --]

Hi Bruno and Branden,

On 2/7/23 15:13, Bruno Haible wrote:
> G. Branden Robinson wrote:
>> groff's had an assert.h header
>> since version 1.01 (1991), but I don't know why.  In 2020 I expanded it
>> to support C99-style assertions (i.e., assertions that communicate
>> meaning instead of the nearly useless form from C89).  I am trying to
>> not require C99 features; we can do without variable-length arrays and
>> complex numbers.  But as a developer I insist on C99 assertions.
> 
> The Gnulib manual [1] explains that Gnulib essentially assumes C99
> already. I still have access to a machine with a pre-C99 compiler,
> but I don't use it for testing any more, since there's no point in
> using a 20-years old compiler that would barf on 50% of the source
> files.

+1

I suggest declaring C89 a unsupported language version, and requiring a minimum 
of C99 (if not C11).  I worked on upgrading shadow-utils recently from C89 to 
C11, so I may help if you need some help.

<https://github.com/shadow-maint/shadow/issues/600>

> 
> We haven't tested the behaviour of <assert.h> in detail, but you're
> *very* likely to get the C99 assertions that you want everywhere.
> 
>> might require #include_next
> 
> Note that #include_next requires GCC or clang. So it is much more
> of a portability constraint than merely requiring C99 or newer.
> 
> Therefore:
>    - How about removing groff's src/include/assert.h and just rely
>      on the one from the system?

+1

>    - If that does not work out, how about putting the src/include/assert.h
>      into a different directory and adjust the -I options, so that
>      the Gnulib compilation units will not see it? Only the groff C++ code
>      would see it.

Yep, I suggest using src/include/groff/ as a root for all groff includes, and 
use -I src/include, so that you need to include groff's headers as "groff/...", 
which can't collide with anything else.

Cheers,

Alex

> 
> Bruno
> 
> [1] <https://www.gnu.org/software/gnulib/manual/html_node/Portability-guidelines.html>
> 
> 
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 14:03       ` Alejandro Colomar
@ 2023-02-07 14:20         ` Bruno Haible
  2023-02-07 14:25           ` Alejandro Colomar
  0 siblings, 1 reply; 11+ messages in thread
From: Bruno Haible @ 2023-02-07 14:20 UTC (permalink / raw)
  To: G. Branden Robinson, bug-gnulib; +Cc: bug-gnulib, groff, Alejandro Colomar

Alejandro Colomar wrote:
> the last reducts of GCC defaulting to gnu89

The default standard version of GCC doesn't matter. The AC_PROG_CC macro
invocation in configure.ac arranges to add the suitable command-line options,
so that the C compiler understands C99 (or even C11 if possible).

Bruno





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 14:20         ` Bruno Haible
@ 2023-02-07 14:25           ` Alejandro Colomar
  0 siblings, 0 replies; 11+ messages in thread
From: Alejandro Colomar @ 2023-02-07 14:25 UTC (permalink / raw)
  To: Bruno Haible, G. Branden Robinson, bug-gnulib; +Cc: groff


[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]

Hi Bruno,

On 2/7/23 15:20, Bruno Haible wrote:
> Alejandro Colomar wrote:
>> the last reducts of GCC defaulting to gnu89
> 
> The default standard version of GCC doesn't matter. The AC_PROG_CC macro
> invocation in configure.ac arranges to add the suitable command-line options,
> so that the C compiler understands C99 (or even C11 if possible).

It matters to me, because nginx (my job) doesn't use autotools, and doesn't 
specify a language version, so it compiles with whatever the system default is. 
And we support CentOS7, so we need to support gnu89.  I've battled a lot to 
specify gnu11 in the cc command line, but so far I've repeatedly met a stone 
wall of unjustified FUD, and the patch didn't make it.

Which means I can't use loop variables or C99 inline. :(

> 
> Bruno

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
  2023-02-07 14:13       ` Bruno Haible
  2023-02-07 14:20         ` Alejandro Colomar
@ 2023-02-10  0:50         ` G. Branden Robinson
  1 sibling, 0 replies; 11+ messages in thread
From: G. Branden Robinson @ 2023-02-10  0:50 UTC (permalink / raw)
  To: Bruno Haible; +Cc: Alejandro Colomar, bug-gnulib, groff

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

Hi Bruno,

At 2023-02-07T15:13:28+0100, Bruno Haible wrote:
> The Gnulib manual [1] explains that Gnulib essentially assumes C99
> already. I still have access to a machine with a pre-C99 compiler,
> but I don't use it for testing any more, since there's no point in
> using a 20-years old compiler that would barf on 50% of the source
> files.

My only reason for retaining a groff-private assert.h was for
portability to ISO C90...

> We haven't tested the behaviour of <assert.h> in detail, but you're
> *very* likely to get the C99 assertions that you want everywhere.

Let's see what happens.  :)

> Therefore:
>   - How about removing groff's src/include/assert.h and just rely
>     on the one from the system?

Thank you very much for your help with this.  I've pushed this change.

If users of macOS of recent vintage would like to pull groff Git HEAD
and try a build, I'd appreciate hearing of your experiences.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-02-10  0:51 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-06  8:29 [g.branden.robinson@gmail.com: macOS 12.6.3 and vasnprintf compilation failure] G. Branden Robinson
2023-02-07  1:06 ` Bruno Haible
2023-02-07  2:01   ` Bjarni Ingi Gislason
2023-02-07 13:04   ` Alejandro Colomar
2023-02-07 13:43     ` macOS 12.6.3, static_assert, and vasnprintf compilation failure G. Branden Robinson
2023-02-07 14:03       ` Alejandro Colomar
2023-02-07 14:20         ` Bruno Haible
2023-02-07 14:25           ` Alejandro Colomar
2023-02-07 14:13       ` Bruno Haible
2023-02-07 14:20         ` Alejandro Colomar
2023-02-10  0:50         ` G. Branden Robinson

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