According to POSIX.1-2004 only SIGPOLL and SIGVTALRM are marked as XSI. This can break build on FreeBSD unlike NetBSD and OpenBSD. $ cc a.c a.c:6:9: error: use of undeclared identifier 'SIGTRAP' 6 | raise(SIGTRAP); | ^ 1 error generated. $ cat a.c #define _POSIX_C_SOURCE 200112L #include <signal.h> int main(void) { raise(SIGTRAP); return 0; } See also https://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html https://github.com/netbsd/src/commit/579c2072dde4 https://github.com/openbsd/src/commit/8aa35f3ee488
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=69beefcd6c22c38ec003efafe329d59481d02d70 commit 69beefcd6c22c38ec003efafe329d59481d02d70 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2024-01-31 05:24:05 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2024-01-31 05:33:40 +0000 x11-wm/wlmaker: unbreak build on non-x86 architectures Upstream defines _POSIX_C_SOURCE to 1, 199309L, 200112L, 200809L in multiple files, all of which hide SIGTRAP on FreeBSD. Drop POSIX as BSD (unlike GNU) enable extensions by default. submodules/libbase/subprocess.c:496:9: error: use of undeclared identifier 'SIGTRAP' 496 | BS_ASSERT(rv == subprocess_ptr->pid); | ^ submodules/libbase/assert.h:45:13: note: expanded from macro 'BS_ASSERT' 45 | BS_ABORT(); \ | ^ submodules/libbase/assert.h:34:28: note: expanded from macro 'BS_ABORT' 34 | #define BS_ABORT() { raise(SIGTRAP); } | ^ PR: 276743 Reported by: pkg-fallout (aarch64) x11-wm/wlmaker/Makefile | 3 +++ 1 file changed, 3 insertions(+)
I'll look. These were right many years ago, but more recent posix standards added to what was defined.
Your reading of the POSIX group's web site is in error. the start marks on on the signals you specify, but the end marks are elsewhere (SIGTRAP and SIGXFSZ respectively). The website is confusing, but it's like this all over the place in these standards. The printed standard has them clearly shaded, at least for issue6 and the forthcoming issue 8. SIGTRAP (and other signals) are all defined as XPG in this standard, the XSI start marker ENDS at the end of SIGTRAP if you look at the web site. The printed standard (as well as the last available issue 6 draft) has them highlighted as XSI rather than the confusing symbol on the web site. I don't have the issue 7 standard standard, but the website has the same start/end marks. The issue 8 draft standard has the clearly highlighted as well. FreeBSD is strictly standards conformant. Neither the NetBSD nor the OpenBSD commits cite a reference and just assert it. These are at best secondary sources. However, neither musl nor glibc appear to implement this hygiene, most likely owing to the fact that Linux has these values as MD values and the MD files are not at all careful to implement strictness in many ways (both the glibc original and the reimplementation in musl). musl is generally not compliant with POSIX hygiene requirements. gilbc's conformance tests test for the right thing, but glibc doesn't pass this test for signals. The question becomes, do we want to maintain the strict interpretation, or do we want to relax it like others implement and adopt this as an extension.
Given that the problem appears to be worked around, and comment 3 explains why this is arguably not a FreeBSD bug, is there anything else to do? Are other ports affected by this?
(In reply to Mark Johnston from comment #4) > comment 3 explains why this is arguably not a FreeBSD bug, Indeed. I've confirmed SIGTRAP is XSI by looking at POSIX drafts on open-std.org. Given SIGSYS is XSI but FreeBSD makes it visible in POSIX I wouldn't emphasize "strictly". > is there anything else to do? Need to report to wlmaker upstream as it'd may manifest on their CI. > Are other ports affected by this? I didn't check. Removing -D_POSIX_C_SOURCE is very common in ports/, sometimes such hacks are upstreamed.
Also, as comment 3 said there's a POSIX bug in HTML rendering. Should probably be reported on https://austingroupbugs.net/ but I'm not familar with the process.
(In reply to Jan Beich from comment #5) In that case I'll close this report, since there don't seem to be any changes warranted for the base system. Please reopen if you disagree.