[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59853ef30ea5fded2693cc2d18ebcf8a@ispras.ru>
Date: Fri, 02 Jun 2023 18:54:28 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: __convert_scm_timestamps() probably breaks with struct
timeval
On 2023-06-02 17:49, Markus Wichmann wrote:
> Hi all,
>
> I couldn't think of a better subject. For unrelated reasons, today I
> stumbled upon the abovenamed function. It looks through all control
> messages in a msghdr, looking for SCM_TIMESTAMP_OLD and
> SCM_TIMESTAMPNS_OLD, and converting an array two long into an array of
> two long long.
>
> This will work with struct timespec (or SCM_TIMESTAMPNS_OLD) on all
> architectures, because struct timespec has been defined specifically
> for
> this to work (due to the kernel accessing it the same way). But it will
> break with struct timeval (or SCM_TIMESTAMP_OLD).
>
> First of all, on some 32-bit archs (and this code is only used on
> 32-bit
> archs) we have alignof(int64_t) == 4, and therefore sizeof (struct
> timeval) == 12. Therefore CMSG_LEN(sizeof (long long[2])) !=
> CMSG_LEN(struct timeval), and therefore, applications won't read the
> newly converted cmsg. All the work for nothing.
Hi,
timeval is specified in alltypes.h.in as:
STRUCT timeval { time_t tv_sec; suseconds_t tv_usec; };
And suseconds_t as:
TYPEDEF _Int64 suseconds_t;
So timeval and timespec structs have the same layout in musl, and it
matches long long[2]. Maybe you assumed that suseconds_t is a 32-bit
type?
Alexey
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.
