[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

From: Alejandro Colomar
Subject: Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
Date: Tue, 7 Feb 2023 15:03:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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: <>

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 <>:

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


[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. :(



GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]