Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160225183109.GW9349@brightrain.aerifal.cx>
Date: Thu, 25 Feb 2016 13:31:09 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Jaydeep Patil <Jaydeep.Patil@...tec.com>,
	Mahesh Bodapati <Mahesh.Bodapati@...tec.com>
Subject: Re: mips n64 porting review

On Thu, Feb 25, 2016 at 07:23:36PM +0100, Szabolcs Nagy wrote:
> * dalias@...c.org <dalias@...c.org> [2016-02-25 13:01:50 -0500]:
> > On Thu, Feb 25, 2016 at 12:05:33PM +0000, Jaydeep Patil wrote:
> > > and all st_*tim members are of 16 bytes
> > 
> > Uhg. Does mips64 actually use a 32-bit time_t? If so I think with
> 
> i think time_t is always __kernel_long_t in linux uapi.
> (which is surely 64bit on mips64)

Okay, that's good to know. Apparently their 'struct stat' is just
completely unusable from userspace without conversion because the
types are wrong. This is also going to lead to a nasty hidden Y2038
bug where the system looks Y2038-ready but the kernel returns
truncated file timestamps. Fixing dynamic-linked programs will be easy
(just upgrade libc.so to use whatever new syscall the kernel adds) but
for static-linked ones the bug will remain buried until it blows up..
(unless you use strace to check for it)

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.