Michael Kerrisk [Fri, 24 Jun 2005 12:38:56 +0000 (12:38 +0000)]
The return value of isinf() changed in glibc 2.02
to differentiate positive and neagtive infinity.
See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285765
Michael Kerrisk [Thu, 23 Jun 2005 10:01:26 +0000 (10:01 +0000)]
Noted use of atexit() for establishing function to be invoked on shared library
unload.
Noted that atexit()-registered functions are not invoked on abnormal
termination.
Formatting fixes.
Michael Kerrisk [Wed, 22 Jun 2005 09:53:58 +0000 (09:53 +0000)]
Consistent use of terms "open file description",
"file status flags", and "file decriptor flags"
Some rewriting of discussion of file descriptor flags
Under F_DUPFD, replaced some text duplicated in dup.2 with a cross ref to dup.2
Minor wording and formatting fixes
Michael Kerrisk [Wed, 22 Jun 2005 09:53:00 +0000 (09:53 +0000)]
Consistent use of terms "open file description",
"file status flags", and "file decriptor flags"
Removed mention of lock sharing -- it was not accurate.
Minor formatting fixes
Michael Kerrisk [Tue, 21 Jun 2005 14:43:56 +0000 (14:43 +0000)]
Clarified semantics of relationship between flock() locks
and open file entries and file descriptors.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291121
Michael Kerrisk [Tue, 21 Jun 2005 11:20:42 +0000 (11:20 +0000)]
When specifying resolved_path as NULL, realpath()
will (still) only allocate up to PATH_MAX bytes.
Plus other minor changes.
See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239424
Because RAND_MAX is equal to INT_MAX, the following expression
contained in the manpage for rand(3) is slightly incorrect.
j=1+(int) (10.0*rand()/(RAND_MAX+1.0));
The correct expression should use parentheses to group the division
before the multiplication, thus yielding:
j=1+(int) (10.0*(rand()/(RAND_MAX+1.0)));
This is not an error where 10.0 is a floating point number, however
where 10.0 is replaced with an integer, this will cause the expression
to always evaluate to 1. (The addition of two parentheses would make
this bug a lot more difficult to make.)
Michael Kerrisk [Fri, 17 Jun 2005 11:33:07 +0000 (11:33 +0000)]
BUGS: In kernels < 2.6.9, EPOLL_CTL_DEL required a non-NULL
'event', even though this argument is ignored.
As per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306517.
Michael Kerrisk [Wed, 15 Jun 2005 12:56:21 +0000 (12:56 +0000)]
Various wording and formatting fixes.
Incorporated some new /proc/sys/net/ipv4/tcp_* file descriptions
from the 2.6.12 source file Documentation/networking/ip-sysctl.txt.
Michael Kerrisk [Mon, 13 Jun 2005 09:01:49 +0000 (09:01 +0000)]
Salut Olivier (and Nishanth),
Regarding man page documentation of the problem of short sleeps
for setiteimer(2)...
> > -- pointers to those threads
>
> http://bugzilla.kernel.org/show_bug.cgi?id=4569
> http://lkml.org/lkml/2005/4/29/163
>
> > -- indications of which kernel versions show this bahaviour
>
> AFAIK, all versions as far as x86 is concerned.
> Dunno if it is hardware specific.
>
> > -- a (short) test program to demonstrate it, if you have one.
>
> See the bugzilla bug's attachments
Sorry for the long delay in following this up, but I've got to
it now. I tweaked your suggestions slightly:
{{
Timers will never expire before the requested time,
-instead expiring some short, constant time afterwards, dependent
-on the system timer resolution (currently 10ms).
+but may expire some (short) time afterwards, which depends
+on the system timer resolution and on the system load.
+Upon expiration, a signal will be generated and the timer reset.
+If the timer expires while the process is active (always true for
+On certain systems (including x86), the Linux kernel has a bug which will
+produce premature timer expirations of up to one jiffy under some
+circumstances.
}}
Thanks for this bug reporet,
Nishanth: if and when your changes are accepted, and the problem
is thus fixed, could you please send me a notification of that
fact, and I can then further amend the manual pages.
Cheers,
Michael
/* itimer_short_interval_bug.c
June 2005
In current Linux kernels, an interval timer set using setitimer()
can sometimes sleep *less* than the specified interval.
This program demonstrates the behaviour by looping through all
itimer values from 1 microsecond upwards, in one microsecond steps.
*/
/* Adapted from a program by Olivier Croquette, June 2005 */