[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAECwjAhpQMfz3vRWX=VFfJTBt+=950_fJnEj6H-6h05Vk85zjg@mail.gmail.com>
Date: Fri, 24 Mar 2017 21:05:15 +0800
From: Yousong Zhou <yszhou4tech@...il.com>
To: Pedro Alves <palves@...hat.com>
Cc: gdb-patches@...rceware.org, musl@...ts.openwall.com,
Rich Felker <dalias@...ifal.cx>
Subject: Re: [PATCH] Fix invalid sigprocmask call
On 24 March 2017 at 20:55, Pedro Alves <palves@...hat.com> wrote:
> On 03/24/2017 12:23 PM, Yousong Zhou wrote:
>> On 24 March 2017 at 18:47, Pedro Alves <palves@...hat.com> wrote:
>>> On 03/24/2017 03:01 AM, Yousong Zhou wrote:
>>>> The POSIX document says
>>>>
>>>> The pthread_sigmask() and sigprocmask() functions shall fail if:
>>>>
>>>> [EINVAL]
>>>> The value of the how argument is not equal to one of the defined values.
>>>>
>>>> and this is how musl-libc is currently doing. Fix the call to be safe
>>>> and correct
>>>>
>>>> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_sigmask.html
>>>>
>>>
>>> I don't agree. It's a musl bug. Please fix it / file a musl bug.
>>
>> I already did that before sending to gdb-patches
>>
>> http://www.openwall.com/lists/musl/2017/03/24/1
>>
>> I am aware of the fact that the current code works with glibc and mac
>> osx 10.11.6. The Linux kernel code at the moment also accepts the
>> call with how==0
>
> Cool.
>
>>
>> But this is more about interpretation of POSIX document itself. And
>> it says, clearly without pre-condition words or ambiguity in the
>> ERRORS section of that page, to return EINVAL if how is not equal to
>> one of the defined values.
>
> The standard wasn't built on a vacuum. It starts by ratifying common
> implementation behavior. If no historical implementation behaves like what
> you're suggesting, what's the point of enforcing that, when it's clearly
> NOT the intent? You're just causing porting pain for no good reason.
> Please file a bug against the standard to have the error section clarified instead.
Lol, now I will consider the idea of bumping the door of POSIX committee ;)
>
>>
>> I also tried to find some posix-compliant testsuite and to search the
>> github code for samples of pthread_sigmask call. The first I came
>> across was the following code snippet at link
>> https://github.com/juj/posixtestsuite/blob/master/conformance/interfaces/pthread_sigmask/8-1.c#L57
>>
>> pthread_sigmask(SIG_BLOCK, NULL, &oactl);
>
> The fact that that call includes SIG_BLOCK doesn't say whether
> passing 0 should be rejected.
>
> So I cloned that repo, and did a quick grep. And lo:
>
> https://github.com/juj/posixtestsuite/blob/26372421f53aeeeeeb4b23561c417886f1930ef6/conformance/interfaces/fork/12-1.c#L187
>
> /* Examine the current blocked signal set. USR1 & USR2 shall be present */
> ret = sigprocmask( 0, NULL, &mask );
>
> if ( ret != 0 )
> {
> UNRESOLVED( errno, "Sigprocmask failed in child" );
> }
>
> Thanks,
> Pedro Alves
>
Okay, then another fact that the posixtestsuite project also expects
to accept how==0
I am cc-ing musl-libc list now.
Regards,
yousong
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
