NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/37726: request documentation of 2147 second limit on adjtime(2)



>Number:         37726
>Category:       kern
>Synopsis:       request documentation of 2147 second limit on adjtime(2)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 09 13:00:00 +0000 2008
>Originator:     Dave B
>Release:        NetBSD 3.1_STABLE / i386
>Organization:
>Environment:
Many versions / platforms are probably affected.  A quick Google
search suggested the problem existed in, e.g., FreeBSD in 1999, as
well.
>Description:
If I pass a value of 2147 (long) in tv_sec, adjtime()
works fine--and the clock gradually advances; however, if
I pass a value of 2148 or greater, it returns success, yet
the clock starts to slow down--and a subsequent call
adjtime() returns erroneous, negative values in
olddelta.tv_sec and olddelta.tv_usec.

>How-To-Repeat:
/* A code snippet which may help. ** adjtime.c ** */

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

int
adjtime( const struct timeval *delta, struct timeval *olddelta );

main( int argc, char *argv[] )
{
  int stat ;
  long l_sec, l_usec ;
  struct timeval delta, olddelta ;

  if ( argc != 2 ) {
    fprintf( stderr, "Usage: %s <(long) seconds to step>\n\n",
      argv[0] );
    exit(1);
  }

  l_sec = atol( argv[1] );

  delta.tv_sec = l_sec ;
  delta.tv_usec = 0L ;

  stat = adjtime( &delta, &olddelta );
  if (stat != 0) {
    perror( "main()/adjtime()" );
  }

  printf( "Old: %ld.%ldsec\n", olddelta.tv_sec, olddelta.tv_usec );
}
>Fix:
Add user-friendly explanation (by someone with the needed language
skills...) of the limitation described above to the adjtime(2) man
page (and maybe to rdate(8)? Although rdate(8) does refer to adjtime(2)
already; so, less necessary).




Home | Main Index | Thread Index | Old Index