struct timeval: why is tv_sec long?

[Andreas Kohn]

Hi,
On Fri, 2005-10-07 at 09:28 -0700, Brooks Davis wrote:
> On Fri, Oct 07, 2005 at 02:22:22AM +0200, Andreas Kohn wrote:
> > Hi,
> > 
> > is there any special reason for timeval.tv_sec being long?
> 
> tv_sec is presumably long becuase that way 64-bit platforms end up with
> timevals that don't suffer from the 2038 bug.  time_t is also long (or
> rather synonimous with it) on all but alpha platforms.

Thanks for this explanation.

As SUSv2 wants tv_sec to be time_t[1], would it be possible to change
this to time_t on all but alpha? I guess alpha will not receive a switch
to long anymore[2]. 
This would still require workarounds as you suggested below for alpha
(nothing changes here), but would at least bring !alpha closer to
standards compliance, which would be a good thing IMVHO.

> > and this fails to compile on FreeBSD. 
> 
> You probably can just cast the tv.tv_sec to a time_t.  Alternativly, you
> could allocate a time_t and assing tv_sec to it since that will work on
> alpha where the other won't.
Yep, I did the latter, and it works. Thanks.

Regards,
Andreas

[1] http://www.opengroup.org/onlinepubs/007908799/xsh/systime.h.html
[2] I read the instructions for sparc64, it that looked ugly and
difficult. 

-- 
<TalisA> was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20051007/61757360/attachment.bin