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;
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.
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
Testing on FreeBSD 5.2.1 shows it doesn't have this problem.
Kernel bug report submitted: