Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
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 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 in a completely different l>anguage is:
>ptr = ffree(ptr)
>where ffree() always returns null.
FFree comes in the case of defensive programming and depending on what is
inside it, it remains a waste.
Probably ffree is written something like this:
void * ffree (void * ptr) {
if (ptr) {
free (ptr)
}
return NULL;
}
I am using only free, without any ifs, and using tools to detect memory
problems, such as DrMemory on Windows.
If a double free occurs, it will certainly be detected either by me or by the
user.
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
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 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 in a completely different language is:
ptr = ffree(ptr)
where ffree() always returns null.
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
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
> 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.
Certainly "call to malloc/calloc must match one call to free" is that is
correct, even if, two free for the same malloc would be double free.
The point is that IF it protects you from double free, only if the pointer is
marked as NULL, after the free as:
if (ptr) {
free(ptr);
ptr = NULL;
}
This is certainly defensive programming and protects the user, but it hides the
fact that they have a double free bug in the program.
At runtime, it makes no difference, calling free with NULL, as long as the
pointer has not been released before.
ptr = NULL;
free(ptr);
The big question is how to catch the double free that may exist.
Because this not to protect agaist double free.
if (ptr) {
free(ptr);
}
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
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
> 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.
Certainly "call to malloc/calloc must match one call to free" is that is
correct, even if, two free for the same malloc would be double free.
The point is that IF it protects you from double free, only if the pointer is
marked as NULL, after the free as:
if (ptr) {
free(ptr);
ptr = NULL;
}
This is certainly defensive programming and protects the user, but it hides the
fact that they have a double free bug in the program.
At runtime, it makes no difference, calling free with NULL, as long as the
pointer has not been released before.
ptr = NULL;
free(ptr);
The big question is how to catch the double free that may exist.
Because this not to protect agaist double free.
if (ptr) {
free(ptr);
}
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
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 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 need the if. Just committed to the SVN. Best, Scuri Em dom, 17 de mai de 2020 10:20, Jörg F. Wittenberger < joerg.wittenber...@softeyes.net> escreveu: > 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 be > released. Let alone changing good code in order to rely on free accepting > a > NULL pointer too. > > > > ___ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users > ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
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 be released. Let alone changing good code in order to rely on free accepting a NULL pointer too. ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
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 Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
