On Tue, Oct 29, 2019 at 03:52:45PM -0400, Rich Felker wrote:
> On Sun, Oct 20, 2019 at 10:46:43PM -0400, Rich Felker wrote:
> > The attached patch series on top of present git master (commit
> > 9b2921bea1d5017832e1b45d1fd64220047a9802) should contain all changes
> > needed for fully working time64 on 32-bit archs, in a form that's
> > plausibly ready for commit (no makeshift hacks just to get things
> > demonstrably working). The one omission I'm aware of is what to do
> > with struct utmpx, which is not actually used at present in any libc
> > interfaces and thus not part of the ABI surface of libc. That will be
> > addressed in a separate thread.
> > 
> > Comments and basic testing are welcome at this point. It should be
> > possible to build for any of the 32-bit archs, but I have only tested
> > build for a few and only tested execution on i386 and sh.
> > 
> > Some useful checks for anyone wanting to help test, especially on the
> > more obscure archs:
> > 
> > [...]
> > 
> > - Anything look odd about time-related types? timeval/timespec members
> >   at positions that aren't naturally aligned?
> 
> I tested this on i386 (with low alignment requirement, only 4 bytes)
> with the attached program and it seems like I indeed got the padding
> slots as-intended on the ipc types. This should mean the adjacent
> explicit-padding members have no effect on other archs using the same
> changes but with natural alignment, which matches the intent. As usual
> mips and ppc are gratuitously different and seemed right to me but
> should perhaps be double-checked at some point. However since they
> have natural alignment the worst that could happen is leaving extra
> padding slots we don't need.

Attachment forgotten, here. Usage is to build against the appropriate
libc/headers and save output, then diff outputs as desired.

Rich