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

2022-03-22 Thread Klaus Jensen
On Mar 15 15:41, 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

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

2022-03-22 Thread Igor Mammedov
On Tue, 15 Mar 2022 15:41:56 +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 errors. >

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

2022-03-16 Thread Pavel Dovgalyuk
On 15.03.2022 17:41, 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 touche

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

2022-03-15 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