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* ^^
signature.asc
Description: This is a digitally signed message part
