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] unsuscribe
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 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 > ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] unsuscribe
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
[Iup-users] Thanks for recent IM and IUP changes...
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: Careful reading of the code shows patterns like:
p_something = (whatever_type *) malloc(some-size);
return = another_function(p_something, param2, param3);
if (! return) then {
get_upset();
}
There is a unlikely, but strictly incorrect, behaviour in the
pseudocode above: malloc(3) may return NULL, and any subsequent
use of a NULL pointer leads to "undefined" behaviour, according
to the standard.
(Even if a non-NULL pointer is returned, some OSes, such as
GNU/Linux, may adopt an optimistic memory allocation strategy,
i.e. merely reporting a virtual memory address. The OS then uses
page faults to map physical memory to the virtual address range,
as read/write activity is executed by the program.
In extreme cases, this may eventually result in the OS using
things like the OOM killer if required: Ultimately, it's possible
that even a non-NULL pointer may still be a poison pill to the
program.)
The point is, dereferencing NULL may cause a segfault, or (worse?)
may lead to memory corruption at some place within the program's
memory map. Clean code should handle a NULL return from malloc(3)
properly, before ANY use of the pointer.)
"Undefined behaviour" means *all bets are off* regarding correct
behaviour of the program, for absolutely all time after the program
steps into "undefined behaviour" territory, until the program ends.
--
cheers,
s-b etc etc
___
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] 2020-05-17: GNU/Linux (Linux Mint 19.3) build status for im-r788, cd-r862, iup-r5904
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. I've downloaded the > latest versions: > > im-r788 > cd-r862 > iup-r5804 > > and have tried it, briefly, on one LinuxMint-19.3 machine. > > I'm pleased to report that IM and CD build successfully, but IUP > fails quickly. It's possibly that the IUP failure is related in > some fashion to the way my rig is configured. > > Following is some notes about today's effort: In particular, I > document what libfftw3 libraries were already present, and what I > downloaded (with follow-on dependencies) to get libfftw3-dev to > install. > > cheers, > > s-b etc etc > > -- Cut here > > IM/CD/IUP GNU/Linux build notes: > * GNU/Linux Mint 19.3 > * gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 > > Resynchronised with latest SVN trees (2020-05-17): > im-r788 > cd-r862 > iup-r5804 > > IM: > (Foolishly tried building im -- failed on fftw3.h) > Used LinuxMint package manager to review fftw3: > libfftw3-single3 already installed > libfftw3-double3 already installed > * Mark libfftw3-dev for installation; pulls in: > libfftw3-bin > libfftw3-long3 > libfftw3-quad3 > * Applied package changes; > im now builds fully (no errors; haven't reviewed warnings); > > CD: > cd builds fully (no errors; haven't reviewed warnings); > > IUP: > Tried iup-r5804 build: Failed to create "dep" directory, > entire build output is 11 lines, reproduced here: > ../tecmake.mak:1805: dep/iup.dep.Linux54_64: No such file > or directory > /bin/sh: 1: cannot create dep/iup.dep.Linux54_64: > Directory nonexistent > ../tecmake.mak:1784: recipe for target > 'dep/iup.dep.Linux54_64' failed > make[2]: *** [dep/iup.dep.Linux54_64] Error 2 > Makefile:12: recipe for target 'iup' failed > make[1]: *** [iup] Error 2 > Makefile:13: recipe for target 'iup' failed > make: *** [iup] Error 2 > pushd /home/lua/tecgraf/1/iup/ > export LC_ALL="C" USE_LUA51 ; make LUA_SUFFIX="" > BIN2C="/usr/bin/lua bin2c.lua" USE_LUA51="Yes" > LUA_INC="/usr/include/lua5.1" USE_PKGCONFIG="Yes" > LUA_LIB="/usr/lib/x86_64-linux-gnu" LUA_BIN="/usr/bin" > LUABIN="/usr/bin/lua" EXCLUDE_TARGETS="iupvled" > popd > > > ___ > 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...
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
