struct timeval

[Kris Kennaway]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20030728/21dfff4b/attachment.bin