I believe g_strndup should be followed by g_free. I tested that the code compiles and runs. But no real runtime testing was done.
<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Parfym och kosmetik upp till 50% billigare hos BeautyPlanet.se - <a style="font-family: Tahoma, sans-serif; font-size: 12px; color: #00f" href="http://secure-dk.imrworldwide.com/cgi-bin/b?ci=aller-kampanj-se&cg=spray&tu=http%3A%2F%2Fwww.beautyplanet.se%2F%3Futm_source%3DSpray%26utm_medium%3DMailfooter%26utm_campaign%3DGenerell" target="_blank">Klicka här!</a> </font>
On Fri, 14 May 2010 23:23:20 -0700, Daniel wrote:
I believe g_strndup should be followed by g_free. I tested that the code compiles and runs. But no real runtime testing was done.
Thank you, committed.
Just for clarity, there is no technical requirement that g_strndup() or similar should be followed by a g_free() instead of free(). g_free() simply calls free() with the difference that it checks for a NULL pointer before which is good in most cases. And using g_free() there is also better for readability.
Regards, Enrico
Le dimanche 16 mai 2010 à 19:46 +0200, Enrico Tröger a écrit :
Just for clarity, there is no technical requirement that g_strndup() or similar should be followed by a g_free() instead of free(). g_free() simply calls free() with the difference that it checks for a NULL pointer before which is good in most cases. And using g_free() there is also better for readability.
Sorry but that's not exactly true: it is in the context of Geany, but 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().
And free(NULL) is always a valid call ;)
Regards, Colomban
On Sun, 16 May 2010 22:40:25 +0200, Colomban wrote:
Le dimanche 16 mai 2010 à 19:46 +0200, Enrico Tröger a écrit :
Just for clarity, there is no technical requirement that g_strndup() or similar should be followed by a g_free() instead of free(). g_free() simply calls free() with the difference that it checks for a NULL pointer before which is good in most cases. And using g_free() there is also better for readability.
Sorry but that's not exactly true: it is in the context of Geany, but
No need for sorry, if at all, I had to say sorry :).
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.
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).
Regards, Enrico
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