[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: G. Branden Robinson
Subject: Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure
Date: Tue, 7 Feb 2023 07:43:26 -0600

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


[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: signature.asc
Description: PGP signature

reply via email to

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