On 25.08.2019 18:10, Joerg Sonnenberger wrote:
> On Sun, Aug 25, 2019 at 04:59:41PM +0100, Roy Marples wrote:
>> On 25/08/2019 16:48, Joerg Sonnenberger wrote:
>>> On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote:
On 25/08/2019 15:39, Joerg Sonnenberger wrote:
> There is no
On Sun, Aug 25, 2019 at 04:59:41PM +0100, Roy Marples wrote:
> On 25/08/2019 16:48, Joerg Sonnenberger wrote:
> > On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote:
> > > On 25/08/2019 15:39, Joerg Sonnenberger wrote:
> > > > There is no technical reason really for prefering void *
> > >
On 25/08/2019 16:48, Joerg Sonnenberger wrote:
On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote:
On 25/08/2019 15:39, Joerg Sonnenberger wrote:
There is no technical reason really for prefering void *
Having to write code to exclusively deal with NetBSD's different API to
compile
On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote:
> On 25/08/2019 15:39, Joerg Sonnenberger wrote:
> > There is no technical reason really for prefering void *
> Having to write code to exclusively deal with NetBSD's different API to
> compile without warnings sounds like a pretty good
On 25.08.2019 17:38, Joerg Sonnenberger wrote:
> On Sun, Aug 25, 2019 at 05:12:26PM +0200, Kamil Rytarowski wrote:
>> I want to see the original state of void* so all casts will be unneded.
>
> But it doesn't. Casts are *still* necesseary when using integer indices
> as data.
>
It's obvious in
On 25/08/2019 15:39, Joerg Sonnenberger wrote:
There is no technical reason really for prefering void *
Having to write code to exclusively deal with NetBSD's different API to
compile without warnings sounds like a pretty good technical reason to me.
And I'm just talking about the C
On Sun, Aug 25, 2019 at 05:12:26PM +0200, Kamil Rytarowski wrote:
> I want to see the original state of void* so all casts will be unneded.
But it doesn't. Casts are *still* necesseary when using integer indices
as data.
> Since B lang times we used pointers and integers as the same data type.
>
On 25.08.2019 16:39, Joerg Sonnenberger wrote:
> On Sun, Aug 18, 2019 at 08:58:15PM -, Valery Ushakov wrote:
>> Joerg Sonnenberger wrote:
>>
>>> On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
Ping? Can we switch from intptr_t to void*?
>>>
>>> Can we just go back to
On Sun, Aug 18, 2019 at 08:58:15PM -, Valery Ushakov wrote:
> Joerg Sonnenberger wrote:
>
> > On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
> >> Ping? Can we switch from intptr_t to void*?
> >
> > Can we just go back to the original state?
>
> Anything wrong with the
On Mon, Aug 19, 2019 at 09:58:32AM +0200, Jaromir Dolecek wrote:
> Please wait with any possible type switch couple more days, I’ll be back from
> vacations on Wednesday and I will check this by then.
>
ping
Please wait with any possible type switch couple more days, I’ll be back from
vacations on Wednesday and I will check this by then.
> Le 18 août 2019 à 17:05, Kamil Rytarowski a écrit :
>
> Ping? Can we switch from intptr_t to void*?
>
> I declare to fix fallout for it.
>
Joerg Sonnenberger wrote:
> On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
>> Ping? Can we switch from intptr_t to void*?
>
> Can we just go back to the original state?
Anything wrong with the templated solution for c++11 I posted a few
days ago, keeping the original state
On 18.08.2019 17:21, Joerg Sonnenberger wrote:
> On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
>> Ping? Can we switch from intptr_t to void*?
>
> Can we just go back to the original state?
>
> Joerg
>
Which original? intptr_t and caller level casts for C++?
signature.asc
On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
> Ping? Can we switch from intptr_t to void*?
Can we just go back to the original state?
Joerg
Ping? Can we switch from intptr_t to void*?
I declare to fix fallout for it.
signature.asc
Description: OpenPGP digital signature
On Wed, Aug 14, 2019 at 06:06:18 +0300, Valery Ushakov wrote:
> static inline void
> EV_SET_(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
> uint32_t _flags, uint32_t _fflags, int64_t _data,
> uintptr_t _udata)
> {
> _kevp->ident = _ident;
> _kevp->filter =
On Sun, Aug 11, 2019 at 03:57:50 +0200, Kamil Rytarowski wrote:
> On 11.08.2019 02:56, Valery Ushakov wrote:
> > Kamil Rytarowski wrote:
> >
> >> Cast of udata from void* to intptr_t shall be done with
> >> reinterpret_cast<> otherwise a C++ compiler errors.
> >>
> >> Defining
On 13.08.2019 21:21, Joerg Sonnenberger wrote:
> On Tue, Aug 13, 2019 at 08:44:04PM +0200, Kamil Rytarowski wrote:
>> void* does not prevent storing inside it numbers.
>
> While not necessarily relevant in the NetBSD context, this is generally
> false. Casting random values to a pointer is UB.
>
On Tue, Aug 13, 2019 at 08:44:04PM +0200, Kamil Rytarowski wrote:
> void* does not prevent storing inside it numbers.
While not necessarily relevant in the NetBSD context, this is generally
false. Casting random values to a pointer is UB.
Joerg
On 13.08.2019 20:22, Jaromir Dolecek wrote:
> I think the rationale was to make it possible to use for integer values and
> operations without cast. And make it clear it can hold arbitrary value, not
> necessarily pointer. Unfortunately intptr_t has different size in 32 vs 64
> bit same as void
I think the rationale was to make it possible to use for integer values and
operations without cast. And make it clear it can hold arbitrary value, not
necessarily pointer. Unfortunately intptr_t has different size in 32 vs 64 bit
same as void *, which I didnt consider.
Using (void *) would
On Mon, Aug 12, 2019 at 03:43:56 +, m...@netbsd.org wrote:
> So, this is when we changed to intptr_t. We also went through a
> "int64_t udata" revision at some point, later.
>
> Module Name:syssrc
> Committed By: jdolecek
> Date: Wed Oct 2 19:09:37 UTC 2002
>
> Modified
From: Christos Zoulas
Subject: Re: EV_SET() better C++ compat with alternative implementations
Date: Sun, 11 Aug 2019 20:08:56 +0300
> Now you get warnings with -Wold-style-cast (which is the reason for __CAST()
> in the first place).
>
> christos
In the C++ case, we could
On 12.08.2019 05:56, Christos Zoulas wrote:
>
>> The original problem is udata of intptr_t insted of void* (like in
>> FreeBSD) and with C++ compilers it's not possible to cast it cleanly to
>> intptr_t without alternative approaches.
>>
>> This keeps breaking C++ users and we need to patch 3rd
> The original problem is udata of intptr_t insted of void* (like in
> FreeBSD) and with C++ compilers it's not possible to cast it cleanly to
> intptr_t without alternative approaches.
>
> This keeps breaking C++ users and we need to patch 3rd party code from
> the caller level.
>
> It used
On Sun, Aug 11, 2019 at 07:38:21PM +0200, Kamil Rytarowski wrote:
> It used to break C ones too, but we have introduced a cast to workaround it.
>
> As we fix it for C ones, I think we should fix it for C++ ones as well.
>
> 3 solutions:
>
> - Keep patching it on caller level for C++
> - Keep
On 11.08.2019 19:19, Kamil Rytarowski wrote:
> On 11.08.2019 19:17, Christos Zoulas wrote:
>> Did you use -Wold-style-cast? We've come full circle now, and what we have
>> seems
>> to be more complicated than what we had before and I am not sure what was the
>> problem in the first place... Can
I don't see how this is possible.
[1:27pm] 345>cat t.cpp
#include
#include
int
main(int argc, char *argv[])
{
printf("%jd", (intptr_t)argv[0]);
return 0;
}
[1:28pm] 346>g++ -std=gnu++11 -Wall -Wold-style-cast t.cpp
t.cpp: In function 'int main(int, char**)':
t.cpp:7:32:
On 11.08.2019 19:22, Christos Zoulas wrote:
> Ok, with what version of event.h, the template specialization?
> I don't see how it is possible to not warn for (cast)foo
>
> christos
>
This is for:
http://netbsd.org/~kamil/patch-00138-EV_SET-CPP-cast.txt
No templates.
signature.asc
Ok, with what version of event.h, the template specialization?
I don't see how it is possible to not warn for (cast)foo
christos
On 11.08.2019 19:17, Christos Zoulas wrote:
> Did you use -Wold-style-cast? We've come full circle now, and what we have
> seems
> to be more complicated than what we had before and I am not sure what was the
> problem in the first place... Can we just step back and understand what is
> the
Did you use -Wold-style-cast? We've come full circle now, and what we have seems
to be more complicated than what we had before and I am not sure what was the
problem in the first place... Can we just step back and understand what is the
problem
we are trying to solve with all this complexity?
On 11.08.2019 19:08, Christos Zoulas wrote:
> Now you get warnings with -Wold-style-cast (which is the reason for __CAST()
> in the first place).
>
> christos
>
For: http://netbsd.org/~kamil/patch-00138-EV_SET-CPP-cast.txt ?
I don't see any related warnings with any C++ -pedantic -Wall
Now you get warnings with -Wold-style-cast (which is the reason for __CAST() in
the first place).
christos
On 11.08.2019 17:21, Kamil Rytarowski wrote:
> On 11.08.2019 14:34, Christos Zoulas wrote:
>> In article <3ebcc5d1-a57d-a290-72d8-6efc73025...@gmx.com>,
>> Kamil Rytarowski wrote:
>>> -=-=-=-=-=-
>>> -=-=-=-=-=-
>>>
>>> On 11.08.2019 02:56, Valery Ushakov wrote:
Kamil Rytarowski wrote:
On 11.08.2019 14:34, Christos Zoulas wrote:
> In article <3ebcc5d1-a57d-a290-72d8-6efc73025...@gmx.com>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 11.08.2019 02:56, Valery Ushakov wrote:
>>> Kamil Rytarowski wrote:
>>>
Cast of udata from void* to intptr_t shall be
In article <3ebcc5d1-a57d-a290-72d8-6efc73025...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 11.08.2019 02:56, Valery Ushakov wrote:
>> Kamil Rytarowski wrote:
>>
>>> Cast of udata from void* to intptr_t shall be done with
>>> reinterpret_cast<> otherwise a C++ compiler
On 11.08.2019 02:56, Valery Ushakov wrote:
> Kamil Rytarowski wrote:
>
>> Cast of udata from void* to intptr_t shall be done with
>> reinterpret_cast<> otherwise a C++ compiler errors.
>>
>> Defining __REINTERPRET_CAST [1] and using it, did not work as a compiler
>> protested for NULL argument
Kamil Rytarowski wrote:
> Cast of udata from void* to intptr_t shall be done with
> reinterpret_cast<> otherwise a C++ compiler errors.
>
> Defining __REINTERPRET_CAST [1] and using it, did not work as a compiler
> protested for NULL argument "warning: passing NULL to non-pointer argument".
>
I propose the following patch to enhance the EV_SET compat with
alternative kqueue/kevent implementations:
http://netbsd.org/~kamil/patch-00133-EV_SET-cpp.4.txt
The current problem:
Cast of udata from void* to intptr_t shall be done with
reinterpret_cast<> otherwise a C++ compiler errors.
40 matches
Mail list logo
