Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Alex Bennée
Markus Armbruster writes: > Philippe Mathieu-Daudé writes: > >> On 15/3/22 14:59, Markus Armbruster wrote: >>> Alex Bennée writes: >>> Markus Armbruster writes: > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > for two reasons. One, it catches mult

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Markus Armbruster
Philippe Mathieu-Daudé writes: > On 15/3/22 14:59, Markus Armbruster wrote: >> Alex Bennée writes: >> >>> Markus Armbruster writes: >>> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two,

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Philippe Mathieu-Daudé
On 15/3/22 14:59, Markus Armbruster wrote: Alex Bennée writes: Markus Armbruster writes: g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, it returns T * rather than void *, which lets the compiler

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Markus Armbruster
Eric Blake writes: > On Mon, Mar 14, 2022 at 05:01:08PM +0100, Markus Armbruster wrote: >> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, >> for two reasons. One, it catches multiplication overflowing size_t. >> Two, it returns T * rather than void *, which lets the compil

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Markus Armbruster
Alex Bennée writes: > Markus Armbruster writes: > >> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, >> for two reasons. One, it catches multiplication overflowing size_t. >> Two, it returns T * rather than void *, which lets the compiler catch >> more type errors. >> > >

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Markus Armbruster
Alex Bennée writes: > Markus Armbruster writes: > >> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, >> for two reasons. One, it catches multiplication overflowing size_t. >> Two, it returns T * rather than void *, which lets the compiler catch >> more type errors. >> >> T

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Dr. David Alan Gilbert
* Markus Armbruster (arm...@redhat.com) wrote: > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > for two reasons. One, it catches multiplication overflowing size_t. > Two, it returns T * rather than void *, which lets the compiler catch > more type errors. > > This commit

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-15 Thread Eric Blake
On Mon, Mar 14, 2022 at 05:01:08PM +0100, Markus Armbruster wrote: > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > for two reasons. One, it catches multiplication overflowing size_t. > Two, it returns T * rather than void *, which lets the compiler catch > more type error

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Alex Bennée
Markus Armbruster writes: > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > for two reasons. One, it catches multiplication overflowing size_t. > Two, it returns T * rather than void *, which lets the compiler catch > more type errors. > > diff --git a/semihosting/conf

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Christian Schoenebeck
On Montag, 14. März 2022 20:48:47 CET Alex Bennée wrote: > Markus Armbruster writes: > > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > > for two reasons. One, it catches multiplication overflowing size_t. > > Two, it returns T * rather than void *, which lets the compile

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Alex Bennée
Markus Armbruster writes: > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > for two reasons. One, it catches multiplication overflowing size_t. > Two, it returns T * rather than void *, which lets the compiler catch > more type errors. > > This commit only touches alloc

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Daniel P . Berrangé
On Mon, Mar 14, 2022 at 05:52:32PM +0100, Markus Armbruster wrote: > Peter Maydell writes: > > > On Mon, 14 Mar 2022 at 16:01, Markus Armbruster wrote: > >> > >> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > >> for two reasons. One, it catches multiplication overflowin

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Cédric Le Goater
On 3/14/22 17:01, Markus Armbruster wrote: g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, it returns T * rather than void *, which lets the compiler catch more type errors. This commit only touches a

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Markus Armbruster
Peter Maydell writes: > On Mon, 14 Mar 2022 at 16:01, Markus Armbruster wrote: >> >> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, >> for two reasons. One, it catches multiplication overflowing size_t. >> Two, it returns T * rather than void *, which lets the compiler ca

Re: [PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Peter Maydell
On Mon, 14 Mar 2022 at 16:01, Markus Armbruster wrote: > > g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, > for two reasons. One, it catches multiplication overflowing size_t. > Two, it returns T * rather than void *, which lets the compiler catch > more type errors. > > Th

[PATCH 3/3] Use g_new() & friends where that makes obvious sense

2022-03-14 Thread Markus Armbruster
g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, it returns T * rather than void *, which lets the compiler catch more type errors. This commit only touches allocations with size arguments of the form si