On Mon, Nov 14, 2016 at 1:27 PM, Scott Lurndal <sc...@lurndal.org> wrote:
...
> The spec says that all members must be part of the structure. It does't mean
> that they each need unique storage _at the same time_. Only the fields
> relevent
> to the signal that caused siginfo_t to be presented to the application need be
> valid for that signal.
I don't think we want to start reading the spec as giving
implementations leeway to overlay arbitrary struct members.
The only other standard struct where I see implementations using a
union to overlay members defined by the standard is struct sigaction,
and for that the standard explicitly says:
The storage occupied by sa_handler and sa_sigaction may
overlap, and a conforming application
shall not use both simultaneously.
(Yes, in6_addr is traditionally a struct containing a union, but the
standard only specifies one member so the overlay doesn't affect a
conforming application)
Looking back: the description of siginfo_t in 1003.1-1996 didn't have
this problem because it only defined 3 members (si_signo, si_code, and
si_value). It was only when additional members were added to the spec
that the bug in the standard's wording occurred, that they were
grouped without clearly stating that no only are some members only
applicable to particular signals+codes, but that they may be overlayed
to match that. IMHO.
Philip Guenther
