Date: Mon, 28 Jul 2003 21:25:06 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Mike Barcroft <mike@FreeBSD.org> Cc: standards@FreeBSD.org Subject: Re: struct timeval Message-ID: <20030729042506.GA61736@rot13.obsecurity.org> In-Reply-To: <20030728234338.B94307@espresso.q9media.com> References: <20030615053705.GA15421@rot13.obsecurity.org> <20030729000206.GA92727@rot13.obsecurity.org> <20030728234338.B94307@espresso.q9media.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Mon, Jul 28, 2003 at 11:43:38PM -0400, Mike Barcroft wrote:
> Here's my copy of my reply:
Thanks. I'm CC'ing it to standards@ so we can try to find a resolution.
> : > I meant to bring up the time_t issue on -standard. I think we can
> : > safely use time_t without binary compatibility problems. Here's the
> : > cases we currently have:
> : >
> : > i386/ia64 time_t == long (no change)
> : > alpha/sparc64 time_t != int (but struct size doesn't change because
> : > suseconds_t is a long)
> : >
> : > Do you foresee any issues?
> :
> : It's not binary-compatible on sparc64's since sparc64 is big-endian. On
> : alphas, there is the problem of garbage in the padding bits. If the
> : type is time_t, then the padding bits may have garbage; binaries compiled
> : when the type was long will see the garbage. I wouldn't change this.
>
> So to properly fix it, we'd have to do new syscalls and expire the old
> ones. A better fix would be to make time_t a long on all platforms.
It seems to me that the bug needs to be fixed before 5.x-STABLE is
branched..someone on IRC looked up the relevant part of POSIX and
claimed that tv_sec is supposed to be a time_t (I cannot confirm this
right now). That means that the following code is compliant, but
breaks on sparc64.
printf("%s\n", ctime(&tv.tv_sec));
Kris
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/JfchWry0BWjoQKURApoTAJ4j66tkteBPANKjNCN4Y0jyI59OMQCgrewz
yHgUTM2GAO3Ak9FRbxa6C18=
=oqBe
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030729042506.GA61736>