[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190815003029.GR9017@brightrain.aerifal.cx>
Date: Wed, 14 Aug 2019 20:30:29 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [RFC] final time64 switch-over patch series
On Wed, Aug 14, 2019 at 08:13:31PM -0400, Rich Felker wrote:
> On Wed, Aug 14, 2019 at 07:55:21PM -0400, Rich Felker wrote:
> > It should be possible to do some macro magic to make features.h do a
> > _T64() function-like macro that expands differently depending on the
> > definition of _REDIR_TIME64 at the time it's expanded, but this will
> > require that all archs define it to 0 or 1 rather than leaving it
> > undefined when not used. Then we can just unconditionally do:
> >
> > int aio_suspend(const struct aiocb *const [], int, const struct timespec *) _T64(__aio_suspend_time64);
> >
> > etc.
> >
> > Does this seem reasonable?
>
> Hm, I think it's probably simpler/more readable just to have
> alltypes.h define _T64(x) appropriately. I hate header mechanisms that
> require you to trace back across arcane stuff in multiple places to
> find how/where something is actually defined.
OK, I started a draft for this and I hate it. It spreads the change
all out interspersed with content that's generic and has nothing to do
with time64-specific archs or even with musl, and makes the headers
gratuitously dependent on a musl-specific _T64 macro being defined
(even if defined away as nothing).
I should probably go the __typeof__ route...
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.
