[[.TP
.B IP_TTL
-Set or retrieve the current time to live field that is send in every
packet
-send from this socket.
+Set or retrieve the current time to live field that is used in every
packet
+sent from this socket.
.TP
.B IP_HDRINCL
]]
[[
swapon(2) indicates that EINVAL wil lbe returned only if the path
specified does not exist or is not a block device.
The kernel will also return EINVAL is a swap signature is not detected
on the indicated path as well.
]]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205736
[[
This example contains the following line:
if ((p = realloc (p, size)) == NULL)
return NULL;
This is a very ill written code, since realloc returning
NULL do not deallocate the original memory block. Such a
statement has a potential to become significant memory
hole. I suggest to correct this example since:
1. It may trick naive programmers to write bad code
2. It may lead skeptic observers to the believe
the whole Linux is written in a similar style.
Regards Jan Kuznik
]]
This guy is right on the money!
I've changed that example, so that the above code has been replaced by:
char *np;
...
if ((np = realloc (p, size)) == NULL) {
free(p);
return NULL;
} else {
p = np;
}
Cheers,
Michael
[[
shm_open(3) refers to O_RWDR during discussion of the possible values of
oflags, and later refers to O_RDWR. The reference to O_RWDR is
incorrect (likely a typo) and should be changed to O_RDWR.
]]
From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: Andries Brouwer <Andries.Brouwer@cwi.nl>
Subject: Re: errno
Hi Andries,
> On Fri, Dec 10, 2004 at 05:07:36PM +0100, Michael Kerrisk wrote:
>
> > I added this text to fcntl.2:
> >
> > BUGS
> > A limitation of the Linux system call conventions means that
> > if a (negative) process group ID to be returned by F_GETOWN
> > falls in the range -1 to -4095, then the return value is
> > wrongly interpreted by glibc as an error in the system call;
> > that is, the return value of fcntl() will be -1, and errno
> > will contain the (positive) process group ID.
>
> Yes.
>
> (Maybe glibc always did this, early libc considered any negative
> return value an error. On the other hand, not all the world is an i386 -
> IBM has just decided that we don't need any i386's anymore
> and sold their stuff to the Chinese - we must use PPC, as Linus
> does already - and on other architectures we do not have this
> ugliness, I think.)
>
> You might consider adding "i386" somewhere:
> A limitation of the Linux i386 system call conventions ...
Some testing on ia64 (RedHat EL 3.0, 2.4.21) and
alpha (2.4.18, Debian 3.0) showed that any negative PGID value
causes F_GETOWN to fail.
My limited reading of the ia64 source:
sysdeps/unix/sysv/linux/ia64/sysdep.h
shows that there is a comment about the -4095 value there,
but that doesn't seem to reflect the reality of the code.
Reading the source, the -4095 limit seems to hold on some
other architectures, e.g.:
sysdeps/unix/sysv/linux/m68k/sysdep.h
sysdeps/unix/sysv/linux/hppa/sysdep.h
sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h
sysdeps/unix/sysv/linux/s390/s390-64/sysdep.h
sysdeps/unix/sysv/linux/x86_64/sysdep.h
Unfortunately, I have no non-x86 systems other than the above
alpha and ia64 (HP-testdrive) on which I can test.
I modified the text a little:
BUGS
A limitation of the Linux system call conventions on some
architectures (notably x86) means that if a (negative) pro‐
cess group ID to be returned by F_GETOWN falls in the range
-1 to -4095, then the return value is wrongly interpreted
by glibc as an error in the system call; that is, the
return value of fcntl() will be -1, and errno will contain
the (positive) process group ID.
I've left a FIXME in the man page source noting that details have
yet to be sorted out for ia64, alpha, etc.
Michael Kerrisk