On Aug 9, 2019, at 7:11 PM, Kamil Rytarowski <n54%gmx.com@localhost> 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>