Michael Kerrisk [Mon, 20 Dec 2004 13:24:38 +0000 (13:24 +0000)]
Pedro Zorzenon
as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242638
Noted use of _XOPEN_SOURCE to get macros <sytdlib.h>
as for wait(2).
mtk
Changed name of argument from 'string' to 'command' (like POSIX).
Noted that glibc does nowadays explicitly check for the existence
of the shell if 'command' is NULL, rather than the older behaviour
of assuming the shell exists and always returning 1 if
'command' is NULL.
Michael Kerrisk [Mon, 20 Dec 2004 11:22:11 +0000 (11:22 +0000)]
Cartsen Hey
as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276248
Changed range for "%S" from 0..61 to 0..60.
SUSv3 says 0..60. I think the manual page probably says
0..61, because that's what SUSv2 said.
(Some other implementations' man pages also say 0..61 --
e.g., Solaris 8 & 9, Tru64 5.1B; FreeBSD 5.1 says 0..60.)
The glibc manual currently says 0..60.
Given that SUSv3 says 0..60, I've changed this the
manual page to also say this:
-The second as a decimal number (range 00 to 61).
+The second as a decimal number (range 00 to 60).
+(The range is up to 60 to allow for occasional leap seconds.)
Michael Kerrisk [Fri, 17 Dec 2004 12:20:07 +0000 (12:20 +0000)]
Martin Schulze, mtk
Removed errno declaration from prototype, added notes
on historical need for this declaration.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174175
Michael Kerrisk [Thu, 16 Dec 2004 14:45:45 +0000 (14:45 +0000)]
Enrico Zini
Added text to clarify that S_IS*() macros should be applied
to st_mode field.
as per: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249698
Michael Kerrisk [Thu, 16 Dec 2004 14:24:00 +0000 (14:24 +0000)]
After bug report from John V. Belmonte
Updated init and quit scripts to reflect kernel 2.4/2.6 reality
(Scripts taken from drivers/char/random.c)
as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247779
[[.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.
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;
}
[[
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.
]]
Michael Kerrisk [Mon, 13 Dec 2004 11:32:37 +0000 (11:32 +0000)]
Date: Mon, 13 Dec 2004 12:09:43 +0100 (MET)
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.:
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 [Fri, 10 Dec 2004 16:28:25 +0000 (16:28 +0000)]
[Further notes on that F_GETOWN bug]
Hi Andries,
[Just for my own reference, I reinclude the pointer to Philippe
Troin's patch
http://marc.theaimsgroup.com/?l=linux-kernel&m=108380640603164&w=2
]
> > > Except of course for fcntl(fd, F_GETOWN) where the owner is a
> > > (negative) process group... If the owning process group has a "low
> > > enough" PGID, it collides with errors and glibc reports an error and
> > > sets errno to -PGID. One might argue that in this instance, that the
> > > BSD's overloading of the pid field with pgids is at fault, but the
> > > bug
> > > still remains :-)
> >
> > I believe that practically speaking this is a non-issue. The
> > lowest PID / PGID that can be allocated to a process other than
> > init or a kernel thread is 300. (RESERVED_PID in kernel/pid.c
> > in 2.6, details differ, but same limit in <= 2.4.)
>
> Hmm. RESERVED_PIDS is used as starting value after overflow,
> not as a starting value at the beginning. I think you are mistaken.
Hmm -- yes. And I was in any case assuming the notion
of a process that might do an F_SETOWN assigning
its own PGID to the socket -- but that might not be so.
And I was overlooking a comment in the fs/fcntl.c
sources that reiterates the point:
case F_GETOWN:
/*
* XXX If f_owner is a process group, the
* negative return value will get converted
* into an error. Oops. If we keep the
* current syscall conventions, the only way
* to fix this will be in libc.
*/
err = filp->f_owner.pid;
force_successful_syscall_return();
break;
And now I've actually created the error in userland code.
It seems that whenever the -PGID retrieved by F_GETOWN is
smaller than 4096, then it is interpreted as an error.
Now I see the relevant code in
sysdeps/unix/sysv/linux/i386/sysdep.h:
==
/* Linux uses a negative return value to indicate syscall errors,
unlike most Unices, which use the condition codes' carry flag.
Since version 2.1 the return value of a system call might be
negative even if the call succeeded. E.g., the `lseek' system call
might return a large offset. Therefore we must not anymore test
for < 0, but test for a real error by making sure the value in %eax
is a real error number. Linus said he will make sure the no syscall
returns a value in -1 .. -4095 as a valid result so we can savely
test with -4095. */
Michael Kerrisk [Thu, 25 Nov 2004 14:39:43 +0000 (14:39 +0000)]
Consolidated mlock.2, munlock.2, mlockall.2, and munlockall.2 material into single page to eliminate duplicated material; updated notes for 2.6.9 changes in permissions and limist on memory locking
projects / thirdparty / man-pages.git / log
