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
Not the way to unsubscribe...
See the link below.
https://sourceforge.net/projects/iup/lists/iup-users/unsubscribe
Best,
Scuri
Em dom., 17 de mai. de 2020 às 21:04, hald via Iup-users <
iup-users@lists.sourceforge.net> escreveu:
> unsuscribe
>
>
> --
> Questa e-mail è stata controllata
unsuscribe
--
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
G'day Antonio (and lua-l list),
Thanks for making some changes. I'll look at them shortly, but will
stay clear of IM, until the next release, unless I stumble over
another GNU/Linux-related breakage.
--
Just to throw a spanner in the works of the others looking at the
"free(NULL)" fun:
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
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
That was a bug in tecmake.mak. Fixed and committed to the SVN.
Best,
Scuri
Em dom., 17 de mai. de 2020 às 00:45, sur-behoffski <
sur_behoff...@grouse.com.au> escreveu:
> G'day,
>
> Thanks for the changes in the last day or so after my previous
> message regarding GNU/Linux LinuxMint builds.
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
10 matches
Mail list logo
