Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 11:51:12AM +0300, Avi Kivity wrote: > qemu_malloc() is type-unsafe as it returns a void pointer. Introduce > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > Signed-off-by: Avi Kivity > --- > > This is part of my memory API patchset, but doesn't really be

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 06:28 PM, Jes Sorensen wrote: > > I guess type safety doesn't matter to you. In my experience it's one of the lesser problems in the code. It's a big issue to someone making widespread changes in the code (like me now). -- error compiling committee.c: too many arguments to f

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/11 17:24, Avi Kivity wrote: > On 07/25/2011 06:21 PM, Jes Sorensen wrote: >> On 07/25/11 17:20, Avi Kivity wrote: >> > On 07/25/2011 06:17 PM, Jes Sorensen wrote: >> >> Using the commands consistently does have an impact, and at least >> with >> >> qemu_malloc() it is obvious what they

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 06:21 PM, Jes Sorensen wrote: On 07/25/11 17:20, Avi Kivity wrote: > On 07/25/2011 06:17 PM, Jes Sorensen wrote: >> Using the commands consistently does have an impact, and at least with >> qemu_malloc() it is obvious what they are and how they behave. The >> proposed macros on

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/11 17:20, Avi Kivity wrote: > On 07/25/2011 06:17 PM, Jes Sorensen wrote: >> Using the commands consistently does have an impact, and at least with >> qemu_malloc() it is obvious what they are and how they behave. The >> proposed macros on the other hand requires everybody to go look up th

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 04:56 PM, Blue Swirl wrote: > qemu_malloc uses g_malloc => you keep tracepoints, you just do not trace > memory allocated by glib Unless the plan is to replace all qemu_malloc() calls with calls to g_malloc(). We can worry when the day comes... there is already another task bloc

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 06:17 PM, Jes Sorensen wrote: Using the commands consistently does have an impact, and at least with qemu_malloc() it is obvious what they are and how they behave. The proposed macros on the other hand requires everybody to go look up the macro to find out what it is trying to do.

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/11 17:15, Anthony Liguori wrote: > On 07/25/2011 10:10 AM, Jes Sorensen wrote: >> On 07/25/11 12:06, Stefan Hajnoczi wrote: +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type > +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type >>> Does this mean we need to

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 10:10 AM, Jes Sorensen wrote: On 07/25/11 12:06, Stefan Hajnoczi wrote: +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type Does this mean we need to duplicate the type name for each allocation? struct foo

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/11 12:06, Stefan Hajnoczi wrote: >> +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type >> > +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type > Does this mean we need to duplicate the type name for each allocation? > > struct foo *f; > > ... > f = qemu_malloc(siz

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 05:58 PM, malc wrote: > > It's annoying that it takes this parameter at all, but I can live with it. > n_structs? Yes. It's 1 in 1-epsilon of all cases. Would have preferred g_new and G_new_array instead. -- error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, 25 Jul 2011, Avi Kivity wrote: > On 07/25/2011 05:47 PM, malc wrote: > > Right right.. only g_new aborts on zero.. > > > > "If n_structs is 0 it returns NULL > . " Right you are. > > It's annoying that it takes

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 5:51 PM, Paolo Bonzini wrote: > On 07/25/2011 04:23 PM, Blue Swirl wrote: >> >> >  Yes.  We can just make qemu_malloc use g_malloc. >> >> It would be also possible to make g_malloc() use qemu_malloc(). That >> way we could keep the tracepoints which would lose their value w

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 04:23 PM, Blue Swirl wrote: > Yes. We can just make qemu_malloc use g_malloc. It would be also possible to make g_malloc() use qemu_malloc(). That way we could keep the tracepoints which would lose their value with g_malloc() otherwise. qemu_malloc uses g_malloc => you keep tra

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 05:47 PM, malc wrote: Right right.. only g_new aborts on zero.. "If n_structs is 0 it returns NULL . " It's annoying that it takes this parameter at all, but I can live with it. -- error compiling com

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, 25 Jul 2011, Anthony Liguori wrote: > On 07/25/2011 09:30 AM, Max Filippov wrote: > > > > > > > > qemu_malloc() is type-unsafe as it returns a void pointer. > > > > > > > > Introduce > > > > > > > > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > > > > > > > > > > > > > J

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 09:30 AM, Max Filippov wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() These bypass qemu_malloc(). Are we okay with that? Yes. We can just make qemu_malloc

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > Just use g_new() and g_new0() > These bypass qemu_malloc(). Are we okay with that? >>> >>> Yes.  We can just make qemu_malloc use

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 09:23 AM, Blue Swirl wrote: On Mon, Jul 25, 2011 at 3:21 PM, Anthony Liguori wrote: On 07/25/2011 07:18 AM, Avi Kivity wrote: On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. I

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 3:21 PM, Anthony Liguori wrote: > On 07/25/2011 07:18 AM, Avi Kivity wrote: >> >> On 07/25/2011 03:11 PM, Anthony Liguori wrote: >>> >>> On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW()

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 05:16 PM, Blue Swirl wrote: There is no escape. Don't make me destroy you. You cannot hide forever, Luke. Touché -- error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 1:09 PM, Avi Kivity wrote: > On 07/25/2011 01:04 PM, Alexander Graf wrote: >> >> On 25.07.2011, at 12:02, Avi Kivity wrote: >> >> >  On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >>  > >> >>  >   That argument can be used to block any change.  You'll get used to >> >> it

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 03:21 PM, Anthony Liguori wrote: On 07/25/2011 07:18 AM, Avi Kivity wrote: On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 04:52 AM, Avi Kivity wrote: On 07/25/2011 12:48 PM, Peter Maydell wrote: On 25 July 2011 10:32, Alexander Graf wrote: > On 25.07.2011, at 10:51, Avi Kivity wrote: >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return t

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 07:18 AM, Avi Kivity wrote: On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0()

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 06:11 AM, Alexander Graf wrote: #define QEMU_NEW_MULTI(type, len) ((type *)(qemu_mallocz(sizeof(type) * len))) char *arr = QEMU_NEW_MULTI(char, 1024); Still not covered: allocating a struct with a variable-size array as final member. I guess a solution for that can be found if

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 03:11 PM, Anthony Liguori wrote: On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() These bypass qemu_malloc(). Are we okay

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 03:51 AM, Avi Kivity wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() Regards, Anthony Liguori Signed-off-by: Avi Kivity --- This is part of my memory API p

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 02:02 PM, Markus Armbruster wrote: Side-stepping the stupid "OMG malloc(0) is weird, therefore we must make qemu_malloc(0) differently weird" controversy would be useful all by itself. If we all work together, we can make this thread even bigger than the tools/kvm pull request.

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 12:32 PM, Alexander Graf wrote: On 25.07.2011, at 10:51, Avi Kivity wrote: > qemu_malloc() is type-unsafe as it returns a void pointer. Introduce > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. What does this buy you over type *x = qemu_malloc(sizeof(type)); ?

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 12:59, Markus Armbruster wrote: > Avi Kivity writes: > >> On 07/25/2011 01:04 PM, Alexander Graf wrote: >>> On 25.07.2011, at 12:02, Avi Kivity wrote: >>> On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >> That argument can be used to block any change. You'll

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

Kevin Wolf writes: > Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: >> On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >>> >>> Signed-off-by: Avi Kivity >

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

Avi Kivity writes: > On 07/25/2011 01:04 PM, Alexander Graf wrote: >> On 25.07.2011, at 12:02, Avi Kivity wrote: >> >> > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >> > >> >> > That argument can be used to block any change. You'll get used to >> >> it in time. The question is, is th

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, 25 Jul 2011, Alexander Graf wrote: > > On 25.07.2011, at 12:09, Avi Kivity wrote: > > > On 07/25/2011 01:04 PM, Alexander Graf wrote: > >> On 25.07.2011, at 12:02, Avi Kivity wrote: > >> > >> > On 07/25/2011 12:56 PM, Alexander Graf wrote: > >> >> > > >> >> > That argument can be u

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 11:25 AM, Kevin Wolf wrote: > Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: >> On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >>> qemu_malloc() is type-unsafe as it returns a void pointer.  Introduce >>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >>>

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: > On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >> >> Signed-off-by: Avi Kivity >> --- >> >> This is part of

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 12:09, Avi Kivity wrote: > On 07/25/2011 01:04 PM, Alexander Graf wrote: >> On 25.07.2011, at 12:02, Avi Kivity wrote: >> >> > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> >> > >> >> > That argument can be used to block any change. You'll get used to >> >> it in time

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 01:06 PM, Stefan Hajnoczi wrote: >char *qemu_strndup(const char *str, size_t size); > > +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type > +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type Does this mean we need to duplicate the type name for each a

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 01:04 PM, Alexander Graf wrote: On 25.07.2011, at 12:02, Avi Kivity wrote: > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> > >> > That argument can be used to block any change. You'll get used to it in time. The question is, is the new interface better or not. >> >> I a

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: > qemu_malloc() is type-unsafe as it returns a void pointer.  Introduce > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > Signed-off-by: Avi Kivity > --- > > This is part of my memory API patchset, but doesn't really belong there

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 12:02, Avi Kivity wrote: > On 07/25/2011 12:56 PM, Alexander Graf wrote: >> > >> > That argument can be used to block any change. You'll get used to it in >> > time. The question is, is the new interface better or not. >> >> I agree that it keeps you from accidently malloc'

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 12:56 PM, Alexander Graf wrote: > > That argument can be used to block any change. You'll get used to it in time. The question is, is the new interface better or not. I agree that it keeps you from accidently malloc'ing a struct of pointer size. But couldn't we also just add t

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 11:52, Avi Kivity wrote: > On 07/25/2011 12:48 PM, Peter Maydell wrote: >> On 25 July 2011 10:32, Alexander Graf wrote: >> > On 25.07.2011, at 10:51, Avi Kivity wrote: >> >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> >> QEMU_NEW() (and QEMU_NEWZ

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 12:48 PM, Peter Maydell wrote: On 25 July 2011 10:32, Alexander Graf wrote: > On 25.07.2011, at 10:51, Avi Kivity wrote: >> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > What does this b

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 07/25/2011 12:43 PM, Alexander Graf wrote: Hm - is there any way to get this without adding upper case C++'ish macros? Switch to C++. -- error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25 July 2011 10:32, Alexander Graf wrote: > On 25.07.2011, at 10:51, Avi Kivity wrote: >> qemu_malloc() is type-unsafe as it returns a void pointer.  Introduce >> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > What does this buy you over > > type *x = qemu_malloc(sizeof(type))

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 11:37, Sasha Levin wrote: > On Mon, 2011-07-25 at 11:32 +0200, Alexander Graf wrote: >> On 25.07.2011, at 10:51, Avi Kivity wrote: >> >>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >> >

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On Mon, 2011-07-25 at 11:32 +0200, Alexander Graf wrote: > On 25.07.2011, at 10:51, Avi Kivity wrote: > > > qemu_malloc() is type-unsafe as it returns a void pointer. Introduce > > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. > > What does this buy you over > > type *x = qemu_ma

Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

On 25.07.2011, at 10:51, Avi Kivity wrote: > qemu_malloc() is type-unsafe as it returns a void pointer. Introduce > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. What does this buy you over type *x = qemu_malloc(sizeof(type)); ? I find the non-C++ version easier to read even.

[Qemu-devel] [PATCH] Introduce QEMU_NEW()

qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Signed-off-by: Avi Kivity --- This is part of my memory API patchset, but doesn't really belong there. qemu-common.h |3 +++ 1 files changed, 3 insertions(+),