View Bug Activity | Format For Printing
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 & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT) + if(txc->modes == 0) + txc->offset = time_adjust; + else if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT) 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. Cheers, Michael
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).
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?
Of course, another response might be: show me some evidence that b) is the case. Is this what you were in fact wanting?
Can you please clarify which of a, b, or c above holds.
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.
Testing on FreeBSD 5.2.1 shows it doesn't have this problem. Kernel bug report submitted: http://bugzilla.kernel.org/show_bug.cgi?id=6761