Le duodi 12 fructidor, an CCXXIII, Michael McConville a écrit :
> 1) Sometimes you have to audit other people's code for memory leaks but
> don't have the time/understanding for logic additions.
Well, in that case, you should be happy: if you have to audit other people's
code and see a
On 01/09/15 04:03, Michael McConville wrote:
> Simon McVittie wrote:
>> The intention throughout the GLib-based stack is that if a
>> g_return[_val]_if_fail() is hit, it indicates that the caller has
>> called the function incorrectly, in a way that is considered to be
>> undefined behaviour
>
>
Simon McVittie wrote:
> On 16/08/15 20:23, Michael McConville wrote:
> > Emmanuele Bassi wrote:
> >> You expected the *_free() functions in GLib to be NULL-safe. They
> >> aren't, except for g_free().
> >
> > g_error_free is. Maybe others too, I haven't checked. It just prints
> > annoying
On Mon, Aug 31, 2015 at 11:03:40PM -0400, Michael McConville wrote:
> 1) print an annoying warning
Not always, as Simon explained already, the g_return_if_fail()/...
functions can be disabled, in which case the program continues its
execution and will usually crash.
See the --enable-debug
Nicolas George wrote:
But maybe I am forgetting another case: can you imagine a code snippet
where g_error_free(error) would make sense with error == NULL?
I may have already mentioned this, but the simplest example is just
adding a g_error_free() at the end of a function when adding a GError*
But if you have an error, shouldn't you either want to a) handle it,
or b) propagate it up?
I can't imagine a case where you want to free a GError without first
attempting to handle it. If you do want to ignore errors, you can
simply pass NULL for a GError ** pointer to a function, since those
Jasper St. Pierre wrote:
Michael McConville wrote:
Nicolas George wrote:
But maybe I am forgetting another case: can you imagine a code snippet
where g_error_free(error) would make sense with error == NULL?
I may have already mentioned this, but the simplest example is just
adding a
On 16/08/15 20:23, Michael McConville wrote:
Emmanuele Bassi wrote:
You expected the *_free() functions in GLib to be NULL-safe. They
aren't, except for g_free().
g_error_free is. Maybe others too, I haven't checked. It just prints
annoying console warnings.
The intention throughout the
On Sat, Aug 15, 2015 at 01:52:02PM -0700, 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.
No, accepting a NULL pointer for free
Hi;
this whole discussion seems to assume that GLib is, somehow, bound to
the C and/or POSIX specs even for API that the C/POSIX specs do not
cover. That is patently false. If we want to discuss improving the G*
platform API, let's do it without using fallacies like appeal to
authority in the
On Sun, Aug 16, 2015 at 10:49:56AM +0100, Emmanuele Bassi wrote:
Consistency is important for a library. It's much simpler to remember
all free/unref functions accept NULL instead of free/g_free accept
NULL, g_object_unref not, g_clear_object yes, etc etc.
unref() is not a free function,
Hi;
On 16 August 2015 at 16:57, Michael McConville
mmcco...@sccs.swarthmore.edu wrote:
Emmanuele Bassi wrote:
this whole discussion seems to assume that GLib is, somehow, bound to
the C and/or POSIX specs even for API that the C/POSIX specs do not
cover. That is patently false. If we want to
Emmanuele Bassi wrote:
this whole discussion seems to assume that GLib is, somehow, bound to
the C and/or POSIX specs even for API that the C/POSIX specs do not
cover. That is patently false. If we want to discuss improving the G*
platform API, let's do it without using fallacies like appeal
Sébastien Wilmet:
No, accepting a NULL pointer for free functions is for convenience. At
the beginning of the block, you initialize your variables at NULL, and
at the end of the block (maybe after a goto label) you free the
variables that need to be freed. It's not a sign of a bug…
On Sun, Aug 16, 2015 at 11:53:16AM +0200, Nicolas George wrote:
Consistency is good, but it is not the only aspect of convenience. Catching
common bugs is another aspect, pulling in the other direction.
When freeing something, there is always the question If I am freeing NULL
here, is it a
Emmanuele Bassi wrote:
Michael McConville wrote:
I wasn't suggesting that it's officially specified. I just think
that this aspect of free() is intentional and useful, and that people
have a reasonable expectation that g_error_free() will conform.
No, people don't have a reasonable
Le nonidi 29 thermidor, an CCXXIII, Sébastien Wilmet a écrit :
So if you design a library like that, your users will need to read the
documentation everytime they use as simple functions as free/unref.
No, only when they consider abusing them.
Consistency is important for a programming
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
26 matches
Mail list logo
