This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: conformtest: Add x32 XFAILs for mq_attr element types (bug 21279) [committed]


On Wed, Mar 22, 2017 at 5:06 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 22 Mar 2017, Zack Weinberg wrote:
>
>> On Mon, Mar 20, 2017 at 5:31 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> > POSIX specifies long as the type of elements of struct mq_attr.
>>
>> I am extremely disappointed to learn that POSIX didn't just make this
>> mistake with struct timespec.
>
> I think it's a lot more plausibly a mistake for mq_attr than for timespec

For clarity, my position is that it is ALWAYS a design error for a
field of a structure in a C-based API spec to be given a bare
fundamental type.  Such structures always wind up needing to be passed
across an ABI discontinuity sooner or later, and you can't be sure you
are allowed to copy them, so you must instead make it possible for
caller and callee to align, and typedefs are the tool C provides to do
that.  The value range is not relevant.

(Yes, this means abstractly we ought to introduce typedefs for e.g.
sa_flags, but there doesn't seem to be any immediate problem there so
it's not urgent.)

(Typedefs named for the quantity in the field - pid_t, uid_t, time_t,
off_t, the hypothetical nsec_t - are a better choice than typedefs
that specify only the size - uintNN_t and friends - because they let
you make changes more easily.  _FILE_OFFSET_BITS=64 was only an option
because off_t already existed.)

(Having said all that, I honestly don't know what the right types are
for struct mq_attr's fields.  The obvious choice is size_t but there's
actually a case that that's too big.)

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]