Date: Tue, 22 Dec 1998 09:48:40 -0500 From: "Kaleb S. KEITHLEY" <kaleb@ics.com> To: freebsd-alpha@FreeBSD.ORG Subject: Re: time_t and clock_t Message-ID: <367FB148.778A1EC3@ics.com> References: <367FA329.7566F4CF@ics.com> <19981222231220B.simokawa@sat.t.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Hidetoshi Shimokawa wrote: > > kaleb> > According to /usr/include/machine/ansi.h, time_t and clock_t are "int" on > kaleb> > alpha and "long" on i386 respectively. I know "int" on alpha and "long" on > kaleb> > i386 are same size 32bit, but I don't think it's resonable that time_t on > kaleb> > alpha is "int". > kaleb> > kaleb> FWIW, time_t and clock_t are also int on Digital Unix. > kaleb> > kaleb> > At least, "tv_sec" part of timeval is declared as "long". > kaleb> > Why don't we change time_t as "long"? > kaleb> > kaleb> Are time_t and clock_t supposed to be 32-bit types? I'll have to check > kaleb> my POSIX specs when I get to work. > > I don't have POSIX specs, so please let me know what specs says. Neither POSIX nor XPG require any particular type, only that it be large enough to hold a particular range of values; e.g. time_t must be large enough to hold a count of the number of seconds in a day, a number that easily fits in an int. > In linux kernel, linux/include/asm-alpha/posix_types.h defines: > typedef long __kernel_time_t; > and linux/include/linux/types.h defines: > typedef __kernel_time_t time_t; Linux is broken in so many different ways -- I personlly wouldn't use Linux as a my pole star. The "Linux Way"® never includes running binaries from other systems, so I'm not surprised that they're incompatible (probably in more ways than just this) with Digital Unix. time_t is also used in struct stat and struct utimbuf (among other possible uses), which hurts a lot more than its use as a return value type for time(). Once I get my Alpha running I might feel more strongly about it, but in the absence of any guiding light about which compat-mode will ultimately be more important: Digital Unix or Linux-Alpha; I don't have any strong feeling about it one way or the other. Assuming that eventually there'll be compat-modes for both, it's clear that which ever type is chosen, one of the compat libcs is going to have to thunk something. Thunking from an int to a long seems less likely to cause gratuitous compiler warnings than the other way around. > kaleb> > It should make our life easier. > kaleb> > kaleb> How so? Using the right type name consistently should be all that's > kaleb> necessary to make life easier, right? > > Some (old) programs includes a line something like: > long time(); > and fails to be compiled. Of course, we should delete the line. > (I found some during package building) These would be fixed in a port, right? That's the FreeBSD Way®. :-) -- Kaleb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?367FB148.778A1EC3>