Re: pthread_setname_np API is bad

[Christos Zoulas <christos%zoulas.com@localhost>]

I understand that I am using contrived examples. I am just pointing out that we don't
usually implement APIs that work 99.9999% of the time when we can implement ones
that work 100% of the time. It is not worth risking problems. You can always provide and
use enhanced ones, but that causes non-portable software. Code that uses 
pthread_setname_np(t, "thread%d", 1) will work on NetBSD and not compile on Linux
the same way code that uses pthread_fmtname_np(t, "thread%d", 1) will... Except that it
will be obvious that pthread_fmtname_np() is a function that NetBSD has and Linux does
not as opposed to an incompatibility in the implementation of pthread_setname_np(), which
will cause the user of the function to try to figure out who's right and how to fix it.
It was a mistake to provide an incompatible pthread_setname_np() in the first place, let's fix
it properly instead of adding a most excellent band-aid.


christos

> On Aug 9, 2019, at 6:39 PM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> 
> On 09.08.2019 17:34, Christos Zoulas wrote:
>> I think we should stop playing games and provide a completely compatible api.
>> If we want enhanced API's, those should be provided as extra. Yes, the magic
>> printf(fmt, ...) works most of the time. How about the case where there is no warning?
>> Like "%%" which will print 1 % on NetBSD and 2 everywhere else? What are you
>> going to do then?
>> 
> 
> In the practical world I saw 0 such issues with our existing API, even
> though it is still vulnerable to it.
> 
>> christos
>> 
>>> On Aug 9, 2019, at 5:06 PM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>>> 
>>> On 09.08.2019 16:03, Martin Husemann wrote:
>>>> On Fri, Aug 09, 2019 at 04:00:02PM +0200, Kamil Rytarowski wrote:
>>>>> On 09.08.2019 15:32, Christos Zoulas wrote:
>>>>>> My worry is that someone will call pthread_setname_np() with a
>>>>>> "%thread%s" name argument and get a core dump on a NetBSD system since
>>>>>> the string will be interpreted as a format (where in other OS's it will
>>>>>> be taken literally and work.
>>>>>> 
>>>>> 
>>>>> This will be caught by a compiler with __printflike() attribute.
>>>> 
>>>> So in response to an incompatible API complaint, we change it to another
>>>> incompatible API?
>>>> 
>>>> Martin
>>>> 
>>> 
>>> My proposal was to keep more or less API compatible one with the current
>>> NetBSD variation but just improve the function prototype.
>>> 
>>> <sanitizer.log>
>> 
> 
> 
> <sanitizer.log>