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
[email protected]
https://lists.sourceforge.net/lists/listinfo/iup-users
