Re: timeval_subtract example

[Mike Frysinger <vapier at gentoo dot org>]

On 01 Feb 2015 21:38, D. Hugh Redelmeier wrote:
> Even though it apparently has two input structs and an output struct, it 
> can actually modify one of the input structs (*y).  This seems like bad
> style.

it is.  you can tell though from the example that this is very old -- it still 
uses old style function prototypes.  much of the manual was written long ago and 
then someone left bereft of updates.  much of it was written when POSIX was not 
as relevant as it is today.

patches def welcome ;)

> POSIX says that the type of tv_usec is suseconds_t.  That type must be 
> able to represent integers in the range -1 through 1000000.
> 
> When can tv_usec be 1000000?  I don't see how POSIX functions can
> generate this value.
> 
> When can tv_usec be -1?  I don't see how POSIX functions can generate
> this value.

considering POSIX only requires the range [-1, 1000000], there are no funcs that 
are required to return values values outside of that range.

> If x->tv_usec is -1 and y->tv_usec is 1000000 then the subexpression
> 	y->tv_usec - x->tv_usec
> might overflow (in the sense that the type not allow the value
> 1000001).  I admit that this is being very pedantic.
> 
> The next line also takes y->tv_usec out of its allowable range
> 	y->tv_usec -= 1000000 * nsec;

POSIX does not say values above/below are forbidden ... it just says that 
systems must be able to support at least that range.  implementations like glibc 
are free to use beyond them, and since this example is in a glibc manual, it's 
perfectly fine to include code that assumes glibc support.

> Should negative durations be representable?  What then is the
> representation of the tv_usec portion?  Is it a positive offset from
> the negative tv_sec?  Or is it an increase of the magnitude of
> tv_usec?  Can anything be inferred from POSIX?
> 
> The BSD functions that are described on timeradd(3) on my Fedora
> system seem to promise results with tv_usec in the range 0 through
> 999999.

i think this example is expecting to deal with users who might pass in weird 
things, not that it expects POSIX functions to return values out of range.

i can't remember the case off the top of my head, but i do recall Linux in some 
cases supporting larger values of tv_usec/tv_nsec automatically.
-mike

Attachment: signature.asc
Description: Digital signature