Le mercredi 19 mai 2010 à 23:10 +0200, Enrico Tröger a écrit : > On Sun, 16 May 2010 22:40:25 +0200, Colomban wrote: > > it isn't in general. g_free() frees a memory chunk with the > > registered free function in the GLib's memory VTable, which by > > default is libc's free() -- and then g_free() and free() are > > equivalent. But if for a reason or another the VTable is set to > > another one, a plain free() may be invalid since the memory may not > > have been allocated by libc's malloc(), calloc() or realloc(). > > Exactly. > Sorry for not being exact enough, actually I didn't mention the above > facts on purpose to not complicate things more than necessary. Don't be sorry either, you're right: the only thing to keep in mind is that GLib's returned memory must be free with GLib's free function. The details generally doesn't matter.
> > And free(NULL) is always a valid call ;) > > Oh, oops. I just checked free(3) on my system and it actually says that > if NULL is passed, no operation is performed. I was quite sure that > results in undefined behaviour. No idea how I got this idea...maybe > it's not true for all systems (systems other than Linux, maybe some > Unices or Windows or who knows :D). Hmm, good question... I just checked to be sure, and C99[1] §7.20.3.2 (at least, I haven't C89 standard at hand) explicitly require free(NULL) to do nothing -- and I'm pretty sure this is also the case with older versions. Then I think it's pretty safe :) Regards, Colomban [1] ISO/IEC 9899 TC3 (C99 committee draft, 2007/09/07) http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
