De: Pete Lomax via Iup-users
Enviado: segunda-feira, 18 de maio de 2020 02:34
Para: IUP discussion list.
Cc: Pete Lomax
Assunto: Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow
free(NULL); " patch...
On Sunday, 17 May 2020, 23:05:05 BST, Ranier Vilela
wrote:
The bi
On Sunday, 17 May 2020, 23:05:05 BST, Ranier Vilela
wrote:
The big question is how to catch the double free that may exist.
Because this not to protect against double free.
if (ptr) {
free(ptr);
}
One tactic I have just recently started adopting, entirely independent of this
and in fact
De: Antonio Scuri
Enviado: domingo, 17 de maio de 2020 17:23
Para: IUP discussion list.
Assunto: Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow
free(NULL); " patch...
> For me those "if"s are there also to remind me that those pointers where not
>
De: Antonio Scuri
Enviado: domingo, 17 de maio de 2020 17:23
Para: IUP discussion list.
Assunto: Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow
free(NULL); " patch...
> For me those "if"s are there also to remind me that those pointers where not
>
For me those "if"s are there also to remind me that those pointers where
not allocated. For me one call to malloc/calloc must match one call to
free. Maybe I'm old, but I'll stick with that for now.
What I can do is to improve the indentation and readability.
Also cm20, cm02 and cm11 don't
On May 17 2020, sur-behoffski wrote:
and are in strict conformance with C's definition of how free(3) is
mandated to work when its parameter is NULL (codified in C89 standard,
and included in all C and C++ standards since).
IMHO it's still better to NOT call free(3) if there is no memory to
As already mentioned, most of the report refers to the third-party library,
where they do not have access.
Could you forward this report to the maintainers of these libraries?
regards,
Ranier Vilela
___
Iup-users mailing list
