[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2019061123563340760322@huawei.com>
Date: Tue, 11 Jun 2019 23:58:00 +0800
From: Li Yu <marvin.tms@...wei.com>
To: Rich Felker <dalias@...c.org>, "musl@...ts.openwall.com"
<musl@...ts.openwall.com>
CC: helitao <helitao@...wei.com>, "Huangqiang (H)" <h.huangqiang@...wei.com>,
Jinyongming <jinyongming@...wei.com>, leijitang <leijitang@...wei.com>,
"liuyutao (C)" <liuyutao2@...wei.com>, "Threefifteen Wang(Kunfeng)"
<threefifteen.wangkunfeng@...wei.com>, "Wudilong (Michael)"
<wudilong@...wei.com>
Subject: Re: Re: [proposal] Add detection of thread ID in pthread-related interfaces
Thanks for your quick and detailed replies first.
As our copy of POSIX 2003.1™-2017, it said such texts in RATIONALE section of pthread_cancel() feature,
'If an implementation detects use of a thread ID after the end of its lifetime, it is recommended
that the function should fail and report an [ESRCH] error. '
I think that it may be a recommended bebhavior in recent revison of POSIX spec.
Another side, in real use cases, many applications are wrote under a major libc implementation first, instead of be wrote according to POSIX spec texts, so I personally think that compatiblity of libc implementation is important than POSIX spec texts, always. In fact, we don't have too many widely usable UNIX variants now.
Last, I think that features of various libc implementations are different is easy to understand and accept, however, someone are crash for same feature is not welcome :) If we wanted to use musl as a core libc in a open system to support various even third-party closed-sources applications, the every new crash after porting new system is not a good news. so, it seem that eveny such open system need to maintain a in-house patch set to provide better robustness.
En, I see, may be, the design goal of musl is not for open system ?
Thanks
--------------
Li Yu
>On Tue, Jun 11, 2019 at 03:57:42PM +0200, Szabolcs Nagy wrote:
>> * pengyuanhong <pengyuanhong@...wei.com> [2019-06-11 11:36:59 +0000]:
>> > I find that all pthread-related interfaces directly access the input
>> > parameter `pthread_t` without any check. If I pass an invalid thread ID
>> > (e.g. an exited thread ID) to these interfaces, then segment fault
>> > happens.
>> >
>> > Both glibc and freebsd can do simple detection of thread ID(pthread_t)
>> > passed by user and return ESRCH when no thread can be found. They
>>
>> that's a historical bug in posix: it required ESRCH
>> which is not possible when the thread id is reused,
>> so all such requirments were removed in posix 2008
>> https://collaboration.opengroup.org/austin/interps/documents/14366/AI-142.txt
>>
>> passing invalid id is simply undefined now, an
> ^^^^
>
>It was always undefined; the text stating that it's undefined was
>present in old POSIX too. The "shall fail" text in the ESRCH errors
>was if "the implementation has detected..." or similar, which oddly
>imposed a requirement to report something if it was detected, but
>didn't (and fundamentally couldn't, since it's undetectable with
>identifier reusage) impose a requirement to detect.
>
>The committee recognized that this made no sense and fixed it by
>removing the "shall fail" text. This was not a functional change, only
>a clarification, and thus didn't require a new version of the
>standard, just a TC.
>
>Rich
>
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.
