Le 07/03/2013 21:41, Dimitar Zhekov a écrit :
On Thu, 07 Mar 2013 20:28:30 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Log Message:
Scope: Fix mismatched allocator/deallocator
These are not mismatched, I'm using strdup() instead of strdup() for strings that must never be NULL.
Huh, what's the difference? Do strdup() behave differently than g_strdup()? (your sentence quoting the same function twice don't help much ;) )
Sorry, I meant "strdup() instead of g_strdup() for strings that must never be NULL".
I guessed that :)
The difference is that strdup(NULL) crashes.
...but strdup() may return NULL because of allocation failure. Maybe just wrap that if you mind, somewhat like Matthew said:
gchar *scope_strdup(const gchar *str) { g_return_val_if_fail(str != NULL, NULL); return g_strdup(str); }
...and you get free debugging hooks on g_return_val_if_fail() :)
Unless we have a policy to always use g_strdup()...
We don't, but note that strdup() is not ISO C.
That's a valid argument, though both *NIX and Win~1 have it.
Yeah practically it's probably not a real concern.
...or there is a real g_/strdup vs. g_/free mismatch somewhere
For example, an obvious mismatch is
foo ? utils_get_locale_from_utf8(start) : strdup(start)
utils_get_locale_from_utf8() allocates with glib, strdup() with libc.
Gee. OK, g_strdup() stays. It may be a bit harder to debug these,
Would it really change much that strdup() succeed but returned NULL, which would probably fail just after if the code didn't handle NULL? It's a wild hope anyway IMHO.
but it's not a bug issue, and certainly not worth mismatches.
...although in practice it's unlikely to be an issue in !win32.
Regards, Colomban