From owner-freebsd-alpha Tue Dec 22 06:48:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA26140 for freebsd-alpha-outgoing; Tue, 22 Dec 1998 06:48:50 -0800 (PST) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from ics.com (ics.com [140.186.40.192]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA26129 for ; Tue, 22 Dec 1998 06:48:45 -0800 (PST) (envelope-from kaleb@ics.com) Received: from ics.com (sunoco.ics.com [140.186.40.142]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id JAA18730 Tue, 22 Dec 1998 09:48:41 -0500 (EST) Message-ID: <367FB148.778A1EC3@ics.com> Date: Tue, 22 Dec 1998 09:48:40 -0500 From: "Kaleb S. KEITHLEY" Organization: Integrated Computer Solutions X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-alpha@FreeBSD.ORG Subject: Re: time_t and clock_t References: <367FA329.7566F4CF@ics.com> <19981222231220B.simokawa@sat.t.u-tokyo.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id GAA26134 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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