Page MenuHomeFreeBSD

Don't declare union semun in userspace unless _WANT_SEMUN is defined.
ClosedPublic

Authored by brooks on Feb 23 2018, 9:47 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 4:23 AM
Unknown Object (File)
Oct 2 2024, 2:47 PM
Unknown Object (File)
Sep 23 2024, 12:30 PM
Unknown Object (File)
Sep 23 2024, 11:58 AM
Unknown Object (File)
Sep 16 2024, 2:51 PM
Unknown Object (File)
Sep 8 2024, 9:50 PM
Unknown Object (File)
Sep 5 2024, 3:38 AM
Unknown Object (File)
Sep 1 2024, 4:00 PM
Subscribers

Details

Summary

POSIX explicitly states that the application must declare union semun.
This makes no sense, but it is what it is.

In a ports exp-run a moderate number of ports fail due to a lack of
approprate autotools-like discovery mechanisms. These issues are
addresses in D14137 which will be committed before this change.

PR: 224300, 224443

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 15236
Build 15300: arc lint + arc unit

Event Timeline

This depends on D14137 and is intended to be committed along with D14490 and D14491.

This revision is now accepted and ready to land.Feb 28 2018, 2:47 AM

I do wonder if it wouldn't be better to break with POSIX in this case and just expose it. Is there something in particular that motivates hiding it besides POSIX compliance?

In D14492#305171, @jhb wrote:

I do wonder if it wouldn't be better to break with POSIX in this case and just expose it. Is there something in particular that motivates hiding it besides POSIX compliance?

I ran into it when trying to run some NetBSD tests since NetBSD is compliant. As things stand we differ from Linux and NetBSD. MacOS put it under:

#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)

The amount we break is minimal in the grand scheme of things and in several cases in ports we're actually breaking local patches to Linux code that we're presumably carrying because upstream doesn't want non-portable changes.

There's no major problem with the current situation but due to the C type system there's no way to write portable C code against this interface unless the target is standards compliant.

That works for me then. It might be helpful to note in the commit message that other OS's also hide it by default.

This revision was automatically updated to reflect the committed changes.