robert@spam.istc.sri.com (04/27/88)
As I've mentioned in this forum before, I'm working on porting
various programs written in C from Sun computers to HP9000/300
computers. One system header file which is on the VAX/Sun but
not on the HP is /usr/include/sys/time.h. Fortunately (?) the
majority of the contents of this file is on the HP, in /usr/include/
time.h. The most noticeable difference, and one which concerns
me, is in the declaration of 'struct timeval'. On the Sun/Vax
the 'tv_sec' field is a "long". On the HP the same field is an
"unsigned long".
I would like to hear from anyone who has ported code which uses
the struct timeval. In particular I'm interested in anyone who
has used timers, or time variables, to key actions in their software.
If you had problems I definately want to hear about it, but if you
didn't have problems I'd also like to know, so that I can make
a SWAG regarding the level of effort I'm likely to encounter in
my porting efforts (ie. is it hopeless or not?).
I would also enjoy hearing from anyone at HP who can explain why
this one small change was made on the HP. Is math done differently
on the HP architecture, or is the kernel time support different from
the Vax/Sun?
Thanks in advance for any words of wisdom.
----------------------------------------------------------------
Robert Allen, robert@spam.istc.sri.com
415-859-2143 (work phone, days)
----------------------------------------------------------------perry@hpfcdc.HP.COM (Perry Scott) (04/28/88)
I believe Posix defines these guys as unsigned long. Perhaps a Posix
guru could confirm.
Perry Scott
..{ihnp4,hplabs}!hpfcla!perry-sdecot@hpisod2.HP.COM (Dave Decot) (05/05/88)
> I believe Posix defines these guys as unsigned long. Perhaps a Posix > guru could confirm. The P1003.1 (POSIX kernel) draft standard does not specify high-precision time routines such as gettimeofday() or gettimer(). Draft 2 of P1003.4 (POSIX Realtime Extension) describes a variety of functions that refer to the following structure, defined in <sys/time.h>: struct timestruc { unsigned long tv_sec; /* seconds */ long tv_nsec; /* and nanoseconds */ }; There is currently no rationale in that document explaining why the tv_sec type is unsigned long. The reason we have unsigned long on HP-UX is to maximize the available range of times for HP-UX systems. tv_nsec does not need to be unsigned because there are only 1 billion nanoseconds in a second. The difference shouldn't affect anything; if you use unsigned long variables to store values of tv_sec in your program, it will work correctly on both HP-UX and Sun systems. Dave Decot hpda!decot
rml@hpfcdc.HP.COM (Bob Lenk) (05/07/88)
HP's primary commitment has always been to AT&T compatibility. The
tv_sec field is unsigned because alarm(2) in SVID (and more recently
POSIX) is specified as dealing with unsigned ints, and alarm(2) and
[gs]etitimer(2) are closely tied in implementation. (The difference
between unsigned ints and unsigned longs doesn't cause a problem since
the struct timeval's unsigned long can always represent alarm's unsigned
int). There is generally no reason to have a struct timeval contain a
negative value. I have heard of cases where arithmetic is done on
struct timevals and checks done for negatives. This will not port
seemlessly to HP-UX, but will port easily (once discovered) with the
proper type casts.
Bob Lenk
{ihnp4, hplabs}!hpfcla!rml
rml%hpfcla@hplabs.hp.com