On 06/08/2017 03:50 AM, Markus Armbruster wrote:
>>> Your script differs from Markus', we should figure out if they can be
>>> merged into one.
>>
>> One notable difference is that I abuse expression, instead of type. I didn't
>> manage to teach spatch about the includes and custom type
On 06/08/2017 03:23 AM, Marc-André Lureau wrote:
>>
>> Your script differs from Markus', we should figure out if they can be
>> merged into one.
>
> One notable difference is that I abuse expression, instead of type. I didn't
> manage to teach spatch about the includes and custom type
Marc-André Lureau writes:
> Hi
>
> - Original Message -
>> On 06/07/2017 02:46 AM, Marc-André Lureau wrote:
>> > The g_new() familly of macros is simpler and safer than g_malloc().
>>
>> s/familly/family/
>>
>> >
>> > "The return pointer is cast to the
Hi
- Original Message -
> On 06/07/2017 02:46 AM, Marc-André Lureau wrote:
> > The g_new() familly of macros is simpler and safer than g_malloc().
>
> s/familly/family/
>
> >
> > "The return pointer is cast to the given type... Care is taken to
> > avoid overflow when calculating the
On 06/07/2017 02:46 AM, Marc-André Lureau wrote:
> The g_new() familly of macros is simpler and safer than g_malloc().
s/familly/family/
>
> "The return pointer is cast to the given type... Care is taken to
> avoid overflow when calculating the size of the allocated block."
>
> I left out the
The g_new() familly of macros is simpler and safer than g_malloc().
"The return pointer is cast to the given type... Care is taken to
avoid overflow when calculating the size of the allocated block."
I left out the common g_malloc(sizeof(*ptr)) pattern, since
alternative "g_new(typeof(*ptr))"