On 09.08.2019 20:52, Christos Zoulas wrote:
> If we make Kamil's suggested ", ...) __printflike" change, then upstream will
> not have to #ifdef __NetBSD__
> the calls.
>
> christos
Not really, it will need at least "|| defined(__NetBSD__)".
signature.asc
Description: OpenPGP digital signatur
On 09.08.2019 20:11, Martin Husemann wrote:
> On Fri, Aug 09, 2019 at 07:09:01PM +0200, Kamil Rytarowski wrote:
>> Delayed adoption of a standardized version of pthread_setname()
>> pthread_getname() will result in no API & ABI breakage with any existing
>> code as we will keep our own _np() invent
If we make Kamil's suggested ", ...) __printflike" change, then upstream will
not have to #ifdef __NetBSD__
the calls.
christos
> On Aug 9, 2019, at 9:11 PM, Martin Husemann wrote:
>
> On Fri, Aug 09, 2019 at 07:09:01PM +0200, Kamil Rytarowski wrote:
>> Delayed adoption of a standardized versi
On Fri, Aug 09, 2019 at 07:09:01PM +0200, Kamil Rytarowski wrote:
> Delayed adoption of a standardized version of pthread_setname()
> pthread_getname() will result in no API & ABI breakage with any existing
> code as we will keep our own _np() invention, at least until we will
> bump major number f
On 09.08.2019 19:10, Kamil Rytarowski wrote:
> On 09.08.2019 19:04, Paul Goyette wrote:
>>
>>
>> On Fri, 9 Aug 2019, Christos Zoulas wrote:
>>
>>> 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
On 09.08.2019 19:04, Paul Goyette wrote:
>
>
> On Fri, 9 Aug 2019, Christos Zoulas wrote:
>
>> 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 chan
On 09.08.2019 18:45, Christos Zoulas wrote:
> 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
On Fri, 9 Aug 2019, Christos Zoulas wrote:
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 pe
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 t
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.% of the time when we can implement
> ones
> that work 100% of the time. It is not worth risking problems. You can always
I understand that I am using contrived examples. I am just pointing out that we
don't
usually implement APIs that work 99.% 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-po
On 09.08.2019 17:39, Kamil Rytarowski 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
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?
> Li
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 everywher
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.
christos
> On Aug 9, 2019, at 4:12 PM, Kamil Rytarowski w
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 sin
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 form
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 wi
On 09.08.2019 14:42, Jaromír Doleček wrote:
> I'd change this immediatelly using the normal rewrite logic in headers
> we use for standard versioning. It would be really good to push this
> into netbsd-9 too.
>
Ah right, we can do __rename() and do it now.
Personally, I find it convenient t
I'd change this immediatelly using the normal rewrite logic in headers
we use for standard versioning. It would be really good to push this
into netbsd-9 too.
Jaromir
Le ven. 9 août 2019 à 14:14, Christos Zoulas a écrit :
>
> In article
> ,
> Matt Turner wrote:
> >On Tue, Aug 6, 2019 at 7:17
In article ,
Matt Turner wrote:
>On Tue, Aug 6, 2019 at 7:17 AM Kamil Rytarowski wrote:
>>
>> On 06.08.2019 07:19, Matt Turner wrote:
>> > On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon wrote:
>> >>
>> >> On Fri, Aug 02, 2019 at 09:29:27PM -0700, Matt Turner wrote:
>> >>>
>> >>> So great,
On Tue, Aug 6, 2019 at 7:17 AM Kamil Rytarowski wrote:
>
> On 06.08.2019 07:19, Matt Turner wrote:
> > On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon wrote:
> >>
> >> On Fri, Aug 02, 2019 at 09:29:27PM -0700, Matt Turner wrote:
> >>>
> >>> So great, you made your API incompatible with everyo
On 06.08.2019 07:19, Matt Turner wrote:
> On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon 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
On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon 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
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.
Thor
On 03.08.2019 06:29, Matt Turner wrote:
> My recent commit [0] in Mesa spawned a discussion [1] about why
> pthread_setname_np()'s parameter 'void *args' is not 'const void *args'.
>
I defer myself from evaluating this proposal, just adding few words:
> Looking in your CVS history, I see that pt
26 matches
Mail list logo
