Re: struct timeval: why is tv_sec long?
On Sat, Oct 08, 2005 at 06:54:22AM +1000, Peter Jeremy wrote: On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote: 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]. tv_sec and time_t are int on Alpha for compatability with Tru64. Since the Alpha is now a dead architecture and no longer a tier-1 FreeBSD platform, it's unlikely anyone will expend the effort to change them. If that is the only reason, make it use time_t and add a fake field on Alpha before or after it (not sure of the byte order) to keep the alignment. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct timeval: why is tv_sec long?
Hi,
On Sat, 2005-10-08 at 06:54 +1000, Peter Jeremy wrote:
On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote:
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].
tv_sec and time_t are int on Alpha for compatability with Tru64. Since
the Alpha is now a dead architecture and no longer a tier-1 FreeBSD
platform, it's unlikely anyone will expend the effort to change them.
That's what I was implying, yes. So, is there any reason left (except
perhaps envious looks from the alpha guys :D) not to change it?
Shall I open up a PR on this?
The only thing I'm currently wondering if it would be better to do
--- sys/_timeval.h
#ifdef __alpha__
long tv_sec;
#else
time_t tv_sec;
#endif
---,
or creating a machine/_timeval.h.
#ifdef __alpha__ would probably okay, there are more files in sys/ that
do that.
I think this is an important issue, as it currently makes code not
compile on FreeBSD that uses standard interfaces.
Attached is a patch to at least update gettimeofday(2) with the fact
that tv_usec is suseconds_t, and add a BUGS section to note the problem
with tv_sec. I was unsure whether to add the reasoning behind the
problem (alpha, tru64), so I left that out.
Best regards,
Andreas
--
TalisA was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
Index: gettimeofday.2
===
RCS file: /storage/freebsd/cvs/src/lib/libc/sys/gettimeofday.2,v
retrieving revision 1.25
diff -u -r1.25 gettimeofday.2
--- gettimeofday.2 2 Jul 2004 23:52:13 - 1.25
+++ gettimeofday.2 8 Oct 2005 16:27:40 -
@@ -82,8 +82,8 @@
.Pp
.Bd -literal
struct timeval {
- long tv_sec; /* seconds since Jan. 1, 1970 */
- long tv_usec; /* and microseconds */
+ long tv_sec; /* seconds since Jan. 1, 1970 */
+ suseconds_t tv_usec; /* and microseconds */
};
struct timezone {
@@ -133,3 +133,5 @@
.Fn gettimeofday
system call appeared in
.Bx 4.2 .
+.Sh BUGS
+The tv_sec member of struct timeval should be a time_t.
signature.asc
Description: This is a digitally signed message part
Re: struct timeval: why is tv_sec long?
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.
--- sys/_timeval.h
/*
* Structure returned by gettimeofday(2) system call, and used in other
calls.
*/
struct timeval {
longtv_sec; /* seconds (XXX should be
time_t) */
suseconds_t tv_usec;/* and microseconds */
};
---
I just stumbled across this code in an application,
---
timeval tv;
gettimeofday(tv, 0);
char tbuf[64];
struct tm tmp;
strftime(tbuf, sizeof(tbuf), %b %d %H:%M:%S, localtime_r(tv.tv_sec,
tmp));
---
and this fails to compile on FreeBSD. I fixed the application code now,
but I do wonder why that XXX in sys/_timeval.h is there.
_timeval.h came into existence on 31-Dec-2002, before that timeval was
defined in sys/time.h with both tv_sec and tv_usec as long.
Could anyone offer any pointers?
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.
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpSVIoqvEbaH.pgp
Description: PGP signature
Re: struct timeval: why is tv_sec long?
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
Re: struct timeval: why is tv_sec long?
On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote: 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]. tv_sec and time_t are int on Alpha for compatability with Tru64. Since the Alpha is now a dead architecture and no longer a tier-1 FreeBSD platform, it's unlikely anyone will expend the effort to change them. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
struct timeval: why is tv_sec long?
Hi,
is there any special reason for timeval.tv_sec being long?
--- sys/_timeval.h
/*
* Structure returned by gettimeofday(2) system call, and used in other
calls.
*/
struct timeval {
longtv_sec; /* seconds (XXX should be
time_t) */
suseconds_t tv_usec;/* and microseconds */
};
---
I just stumbled across this code in an application,
---
timeval tv;
gettimeofday(tv, 0);
char tbuf[64];
struct tm tmp;
strftime(tbuf, sizeof(tbuf), %b %d %H:%M:%S, localtime_r(tv.tv_sec,
tmp));
---
and this fails to compile on FreeBSD. I fixed the application code now,
but I do wonder why that XXX in sys/_timeval.h is there.
_timeval.h came into existence on 31-Dec-2002, before that timeval was
defined in sys/time.h with both tv_sec and tv_usec as long.
Could anyone offer any pointers?
Best regards,
--
Andreas
--
TalisA was macht man eigentlich auf einer linux-gamer lan ? hl server
aufsetzen und freuen ? *duck* ^^
--
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
