From owner-freebsd-standards@FreeBSD.ORG Mon Jul 28 21:25:11 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2017837B401; Mon, 28 Jul 2003 21:25:10 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-135.dsl.lsan03.pacbell.net [63.207.60.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EE0743F93; Mon, 28 Jul 2003 21:25:08 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id EA35C66CFA; Mon, 28 Jul 2003 21:25:06 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id A8B698CB; Mon, 28 Jul 2003 21:25:06 -0700 (PDT) Date: Mon, 28 Jul 2003 21:25:06 -0700 From: Kris Kennaway To: Mike Barcroft Message-ID: <20030729042506.GA61736@rot13.obsecurity.org> References: <20030615053705.GA15421@rot13.obsecurity.org> <20030729000206.GA92727@rot13.obsecurity.org> <20030728234338.B94307@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <20030728234338.B94307@espresso.q9media.com> User-Agent: Mutt/1.4.1i cc: standards@FreeBSD.org Subject: Re: struct timeval X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2003 04:25:11 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 =3D=3D long (no change) > : > alpha/sparc64 time_t !=3D 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 compil= ed > : when the type was long will see the garbage. I wouldn't change this. >=20 > 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 --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/JfchWry0BWjoQKURApoTAJ4j66tkteBPANKjNCN4Y0jyI59OMQCgrewz yHgUTM2GAO3Ak9FRbxa6C18= =oqBe -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1--