Page MenuHomeFreeBSD

arm64: Fix sig_atomic_t limit definitions
ClosedPublic

Authored by brooks on Mar 21 2023, 11:03 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Jun 6, 9:50 AM
Unknown Object (File)
Thu, Jun 6, 9:50 AM
Unknown Object (File)
Thu, Jun 6, 9:49 AM
Unknown Object (File)
Tue, Jun 4, 3:43 PM
Unknown Object (File)
May 8 2024, 5:57 PM
Unknown Object (File)
May 8 2024, 5:57 PM
Unknown Object (File)
May 8 2024, 5:57 PM
Unknown Object (File)
May 8 2024, 1:21 PM
Subscribers

Details

Summary

sig_atomic_t is defined as a long and thus is 64-bit on arm64. For some
reason its limit was incorrectly specified as a 32-bit number. This had
the unfortunate side effect of causing gnulib to override most of the
definitions in stdint.h. On CheriBSD this breaks all software that uses
gnulib in annoying an hard to debug ways.

Technically updating the limits might be an ABI change, but these
defines are largely unused (the only use in tree is in the libc++ test
suite where it's use an assertion that will fail due to this bug).
Further, since the underlying type remains the same, we're just
increasing the range of values a paranoid program might use.

Sponsored by: DARPA

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

also 32-bit limits on RISCV FWIW

(mips also had this same mistake but not worth fixing on stable/13...)

I notice x86 uses __LONG_MIN and __LONG_MAX

I notice x86 uses __LONG_MIN and __LONG_MAX

I'm tempted to switch that to INT64_* and remove the machine/_limits.h pollution added in 703fbbe36fdb6

This revision is now accepted and ready to land.Mar 21 2023, 11:33 PM

I notice x86 uses __LONG_MIN and __LONG_MAX

I'm tempted to switch that to INT64_* and remove the machine/_limits.h pollution added in 703fbbe36fdb6

D39196

My guess is this came via sparc64 which had the same issue.

This revision was automatically updated to reflect the committed changes.