In article <CAEdQ38FPBEFhCTTBKvZFjQbz-B9=gzzw=tuhfprdipoqj3p...@mail.gmail.com>,
Matt Turner <matts...@gmail.com> wrote:
>On Tue, Aug 6, 2019 at 7:17 AM Kamil Rytarowski <n...@gmx.com> wrote:
>>
>> On 06.08.2019 07:19, Matt Turner wrote:
>> > On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon <t...@panix.com> wrote:
>> >>
>> >> On Fri, Aug 02, 2019 at 09:29:27PM -0700, Matt Turner wrote:
>> >>>
>> >>> So great, you made your API incompatible with everyone else for zero
>> >>> gain. /o\
>> >>
>> >> And so forth.
>> >>
>> >> Is there some reason for the snotty attitude? Whether you're right or
>> >> wrong you're not likely to persuade anyone that way.
>> >
>> > Well, yes, actually. It's a waste of my time to deal with useless API
>> > incompatibilities.
>> >
>> > Feel free to disregard my whole email based on the perceived attitude,
>> > if you're unhappy with it.
>> >
>> > I was just trying to do the right thing, and I don't intend to expend
>> > any more effort advocating for this change. It doesn't matter to me
>> > whether you take the suggestion or even whether Mesa works on NetBSD,
>> > but it might matter to you. So, ¯\_(ã)_/¯
>> >
>>
>> I propose to change the function signatures on the next ABI bump to:
>>
>> int pthread_setname_np(pthread_t, const char * restrict format, ...)
>> __printflike(2, 3);
>>
>> int pthread_attr_setname_np(pthread_attr_t *, const char * restrict
>> format, ...*) __printflike(2, 3);
>>
>> This way we will keep API compat for all the current users and keep
>> compiler checks for safe usage.
>>
>> Personally, I find it convenient to use it like pthread_setname_np(t[i],
>> "thread %d, i) and I would like to keep using it.
>
>FWIW, I think that's a better suggestion than either of mine. I support that.
Do we have to wait for an API bump for this? Seems pretty harmless. Although
it is probably better to have:
int pthread_setname_np(pthread_t, const char *);
and
int pthread_fmtname_np(pthread_t, const char * restrict format, ...)
__printflike(2, 3);
christos
