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
