Follow @Openwall on Twitter for new release announcements and other news
[<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.