[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230602165643.GV4163@brightrain.aerifal.cx>
Date: Fri, 2 Jun 2023 12:56:45 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: __convert_scm_timestamps() probably breaks with struct
timeval
On Fri, Jun 02, 2023 at 05:55:23PM +0200, Markus Wichmann wrote:
> Hello,
>
> never mind. I overlooked that you define suseconds_t as _Int64. I
> thought it was long. Of course, that changes everything.
>
> Wondering why I thought it was long, I looked at POSIX again, and it
> says:
>
> |The implementation shall support one or more programming environments
> |in which the [width] of [...] suseconds_t [...] [is] no greater than the
> |width of type long.
>
> (Quoted from https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html)
That's legacy cruft from C89 days that used to require an environment
where off_t is no wider than long, which probably led to the whole
paragraph being ignored.
> So suseconds_t is not supposed to be larger than long. But I suppose you
> can only pick your poison here. Disregard that one requirement of POSIX
> or make timeval and timespec have different representations.
It's not about whether timeval and timespec have different
representations; that'd be fine, and in fact they do!
Rather, it's about whether the user and kernelspace (64-bit) timeval
types are in agreement. If not, there's a lot more mess to deal with.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
