It will fix it in that it will warn and then return NULL (and only if
you build glib with the flag that turns those return_val_if_fail's on,
which it does by default), but it's considered improper behavior to
call g_hash_table_lookup with a NULL key.
On Sat, Aug 15, 2015 at 1:27 PM, Michael
Paul wrote:
Michael McConville wrote:
Paul wrote:
Recently I was re-educated by the Java people that using a null on
free is how they regularly force various Java handling routines
they rely on SEGFAULT.
Is that relevant? This is C, not Java.
What do you Java is written in?
I'm
Jasper St. Pierre wrote:
Lots of things in GLib fail when passed a NULL pointer, like
g_object_unref.
I'm talking about free()-family functions specifically, though. They
have a POSIX-specified behavior that people expect.
The idea is that passing a NULL pointer is probably a sign of a bug
Christian Hergert wrote:
Try g_clear_error(error) instead of g_error_free(error) to get the
effect you want.
I had discovered this workaround. :-) However, I think it would be
really nice if this (very trivial) change were made in glib. For
example, with Pidgin we'd either have to replace
Recently I was re-educated by the Java people that using a null on free
is how they regularly force various Java handling routines they rely on
SEGFAULT.
On 8/15/2015 4:54 PM, Michael McConville wrote:
Jasper St. Pierre wrote:
Lots of things in GLib fail when passed a NULL pointer, like
On Sat, 15 Aug 2015, Jasper St. Pierre wrote:
Lots of things in GLib fail when passed a NULL pointer, like g_object_unref.
The idea is that passing a NULL pointer is probably a sign of a bug
somewhere, so you shouldn't do it. [...]
On the one hand, the function is question is specialized,
Allin Cottrell wrote:
On the one hand, the function is question is specialized, it's not
free(), nor g_free(), and no standard mandates that it should accept a
NULL pointer as a no-op.
Agreed. I wasn't suggesting that it's officially specified. I just think
that this aspect of free() is
On 8/15/2015 7:05 PM, Michael McConville wrote:
Paul wrote:
Recently I was re-educated by the Java people that using a null on
free is how they regularly force various Java handling routines they
rely on SEGFAULT.
Is that relevant? This is C, not Java.
What do you Java is written in?
Lots of things in GLib fail when passed a NULL pointer, like g_object_unref.
The idea is that passing a NULL pointer is probably a sign of a bug
somewhere, so you shouldn't do it. While the C standard's free() is
NULL-safe, I'd say that this is quite strange for the C standard,
since any other
Hi,
On 08/15/2015 02:54 PM, Michael McConville wrote:
Rather than strange, I'd say it was intentional and insightful. In
function bodies, you often have pointers that are used in conditions and
may or may not be null. There's a very easy and clean way to deal with
this: initialize them to
If you call g_error_free() on a null pointer, you'll see something like
this:
(process:345): GLib-CRITICAL **: g_error_free: assertion 'error != NULL'
failed
However, POSIX specifies:
If ptr is a null pointer, no action shall occur.
Currently, if you pass a null key pointer to g_hash_table_lookup(), it
will sometimes segfault in g_str_hash(). This often happened in the
Pidgin development tip until we added this check:
https://hg.pidgin.im/pidgin/main/rev/7e57fa4513f4
I was running GLib 2.44.1 on OpenBSD 5.8
12 matches
Mail list logo
