Bug 2449 - adjtime() does not update oldelta if delta is NULL
Summary: adjtime() does not update oldelta if delta is NULL
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.4
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2006-03-12 22:25 UTC by Michael Kerrisk
Modified: 2018-04-19 13:47 UTC (History)
1 user (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kerrisk 2006-03-12 22:25:38 UTC
According to 'info adjtime', if the OLDDELTA argument is not a NULL 
pointer, then adjtime() returns information about any previous time
adjustment that has not yet completed.

However, this is only done if DELTA is non-NULL (i.e., we
are also changing the adjustment).  If we want to simply retrieve
the current delta without changing it (as the info man page implies
we can), then specifying 'DELTA' as NULL does not cause the 
remaining delta to be returned in OLDDELTA. 

I believe the problem actually lies in the kernel, where the
following patch should fix things:

--- time.c.orig	2006-03-12 11:03:10.000000000 +1300
+++ time.c	2006-03-12 11:04:26.000000000 +1300
@@ -375,7 +375,9 @@
 	    /* p. 24, (d) */
 		result = TIME_ERROR;
+	if(txc->modes == 0)
+	    txc->offset    = time_adjust;
 	    txc->offset	   = save_adjust;
 	else {
 	    txc->offset = shift_right(time_offset, SHIFT_UPDATE);

However, I submit this against glibc, because it is the (more portable)
glibc adjtime() interface that is (IMO) broken by this problem.  If you 
agree that this is the needed fix you can either push it to the 
kernel folk, or ask me to do so.


Comment 1 Ulrich Drepper 2006-04-02 17:35:39 UTC
You don't show a problem in libc.  So, don't waste our time.  Either provide
convincing evidence or take this up with others (liek the kernek people).
Comment 2 Michael Kerrisk 2006-04-02 22:35:52 UTC
Subject: Re:  adjtime() does not update oldelta if delta is NULL

I explained a way in which I believe the glibc implementation of adjtime() 
differed from the 'info' description of adjtime().  That difference is 
entirely a glibc issue.

I expected you would say one of the following:

a) the description under 'info adjtime' is incorrect;

b) the behavior of 'info adjtime' is incorrect -- i.e., it does 
   not conform to the description in 'info adjtime'; or

c) I am wrong in perceiving there is a problem here -- i.e., the
   documented and actual behaviour do not conflict.

Which is it?  I am not clear from your response.

I think that b) holds.  And as I suggested already, I think the cause is a 
kernel issue.  If you agree that b) holds, I'm happy to push the issue 
with kernel folks.  But it is not clear from your response: do you agree 
that b) holds?
Comment 3 Michael Kerrisk 2006-04-02 23:10:10 UTC
Of course, another response might be: show me some evidence that
b) is the case.  Is this what you were in fact wanting?
Comment 4 Michael Kerrisk 2006-04-19 17:43:24 UTC
Can you please clarify which of a, b, or c above holds.
Comment 5 Ulrich Drepper 2006-05-03 06:40:38 UTC
I didn't invent the interface.  From the look of the code it seems like the old
value should be returned regarless of the first parameter.  And I don't see how
the info pages can be interpreted differently.

If the kernel doesn't allow this then go, investigate what BSD does, and file a
bug explaining it, either with the kernel or here.  But you cannot just drop
something like "there might be a problem here" and expect other people to do the
work for you.  Nobody who is using it complained about the libc implementation
so far.
Comment 6 Michael Kerrisk 2006-06-28 13:10:33 UTC
Testing on FreeBSD 5.2.1 shows it doesn't have this problem.
Kernel bug report submitted: