I think we should do something right now (even for NetBSD-9) to avoid causing pain upstream. Even the variadic change is an improvement. I was just arguing that if we were going to make the change, let's go all the way and fix it properly, but if people feel that there is a chance for upstream to adopt the printflike setname_np() (I don't), let's go for it.
christos > On Aug 9, 2019, at 7:11 PM, Kamil Rytarowski <n...@gmx.com> wrote: > > On 09.08.2019 17:47, Christos Zoulas wrote: >> 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. >> >> > > My only reason for my proposal was to keep API compat with the current > users, however we can switch to the Linux API. I still think that these > 0.00001% of cases where it would be broken are in theory, not in > practice.. but we can go for it. > > I will insist on an intermediate step here before any code changes in > libpthread(3). > > I propose to try to push the Linux version to POSIX and in case of > seeing it rejected, adapt the Linux version as is. All currently > relevent POSIX-like OSs already support one or the other _np() variation. > > There is no pressure for a change to do it now, soon or for NetBSD 9.0 > and waiting some weeks/months is fine. If it will land NetBSD 10.0, > there will be no harm. > > <sanitizer.log>