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 <n...@gmx.com> 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 <n...@gmx.com> 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>
