Samuel Thibault <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG, le Tue 17 Jan 2006 13:56:05 -0800, a écrit :
>> The same situation happens with getpgid, and you will see that in the
>> case of getpgid, the C library handles the zero-argument case itself.
>>
>> I believe that the same should be
Hi,
Thomas Bushnell BSG, le Tue 17 Jan 2006 13:56:05 -0800, a écrit :
> The same situation happens with getpgid, and you will see that in the
> case of getpgid, the C library handles the zero-argument case itself.
>
> I believe that the same should be done here, for the sake of
> consistency.
>
Samuel Thibault <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG, le Tue 17 Jan 2006 13:56:05 -0800, a écrit :
>> The same situation happens with getpgid, and you will see that in the
>> case of getpgid, the C library handles the zero-argument case itself.
>
> Well, it is a bit different: I'd int
Alfred M. Szmidt, le Tue 17 Jan 2006 23:55:11 +0100, a écrit :
>The question might be rephrased into: do we want proc server
>interaction to be XSI-compliant, or do we want strict XSI
>compliancy only at libc level?
>
> glibc is the proper place, it should be XSI compliant. proc might
The question might be rephrased into: do we want proc server
interaction to be XSI-compliant, or do we want strict XSI
compliancy only at libc level?
glibc is the proper place, it should be XSI compliant. proc might not
be though.
___
Bug-hur
Hi,
Thomas Bushnell BSG, le Tue 17 Jan 2006 13:56:05 -0800, a écrit :
> The same situation happens with getpgid, and you will see that in the
> case of getpgid, the C library handles the zero-argument case itself.
Well, it is a bit different: I'd interpret the way the C library does it
as an opti
Hi,
Thomas Bushnell BSG, le Tue 17 Jan 2006 11:41:15 -0800, a écrit :
> This patch seems like the right idea.
>
> 1: You should remove the comment that CALLERP is ignored.
> 2: CALLERP may be null if the RPC is received on the wrong kind of
>port (in which case EOPNOTSUPP should be returned).
I think your patch is ok, but I have thought more and think that it is
the wrong place to make this change.
The same situation happens with getpgid, and you will see that in the
case of getpgid, the C library handles the zero-argument case itself.
I believe that the same should be done here, for
Samuel Thibault <[EMAIL PROTECTED]> writes:
> [hurd]/proc/Changelog
> 2006-01-17 Samuel Thibault <[EMAIL PROTECTED]>
>
> Fix setsid(0).
>
> * pgrp.c (S_proc_getsid): When pid == 0, use `callerp' argument
> instead of pid_find(pid).
>
> Index: pgrp.c
> ==
Thomas Bushnell BSG wrote:
Samuel Thibault <[EMAIL PROTECTED]> writes:
Currently, setsid(0) always return 1, while it should return the
sid of the calling process. Here is a proposed patch:
I have no particular objection, but what is the standard that
specifies its return value this way?
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Samuel Thibault <[EMAIL PROTECTED]> writes:
>
>> Currently, setsid(0) always return 1, while it should return the sid of
>> the calling process. Here is a proposed patch:
>
> I have no particular objection, but what is the standard that
> specifie
Thomas Bushnell BSG wrote:
Samuel Thibault <[EMAIL PROTECTED]> writes:
Currently, setsid(0) always return 1, while it should return the
sid of the calling process. Here is a proposed patch:
I have no particular objection, but what is the standard that
specifies its return value this way?
Samuel Thibault <[EMAIL PROTECTED]> writes:
> Currently, setsid(0) always return 1, while it should return the sid of
> the calling process. Here is a proposed patch:
I have no particular objection, but what is the standard that
specifies its return value this way?
Despite the suggestive name o
13 matches
Mail list logo
