[comp.sys.hp] time.h header files on HP9000/300.

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-s

decot@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