Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

[Alejandro Colomar]

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

OpenPGP_signature
Description: OpenPGP digital signature