Re: Nautilus Gtk stuff inventory (for Gtk 2.0?)

[Darin Adler <darin eazel com>]

on 6/28/00 11:19 AM, Owen Taylor at otaylor@redhat.com wrote:

> This is a horrible misunderstanding of why g_strdup() accepts NULL
> and produces NULL.
> 
> NULL is NOT the same as "".

I have never misunderstood this. Sorry if I blurred the notion in my brief
comments. I assure you it is not blurry in the code.

As I said above in the case of nautilus_strcmp, it would be reasonable to
alter the definition of it so that NULL == NULL only and NULL != "", callers
simply require that NULL == NULL and NULL doe not result in a segfault or
warning.

The point is that we have tons of contexts in Nautilus where there are
single strings or lists that include both strings and the lack of a string,
represented by NULL. Having some functions with defined behavior when passed
NULL makes functions dealing with these much simpler and smaller. Perhaps
the real issue is making the NULL behavior a more prominent part of the
function name.

> The convention used throughout GLib/GTK+/GNOME is that NULL used for a
> 'char *' is a special value indicating that the string is undefined,
> unused or something of that sort. It's like 'undef' in Perl.

And that's what we use it for in Nautilus too. The question is, what do you
do in the common case where you write a bit of code that does the same thing
for an empty string and for an undefined string? Must you have an if
statement in each such place, or should you instead create some string
utilities that define what they do with an undefined string rather than
making it illegal to call them?

> With this convention, applying strlen() or strcmp() to a NULL string
> indicates a logic error in the code.

A call to g_strdup with a NULL string could also indicate a logic error.

Why shouldn't an enhanced strcmp tell you if both strings were NULL, and
also say that NULL is < non-NULL? Is there some reason having such a
function would be harmful?

In the case of strlen, I could imagine outlawing NULL, but having a variant
that returns 0 does save a lot of code. An explicit check for NULL can still
be done, and the old strlen still exists and is used in contexts where NULL
is not expected.

> (The only case I can think of where we do allow NULL to be indicate
> empty string is gtk_label_set_text (NULL) and some related
> functions. This is just a convenience and does not indicate that NULL
> is generally the same as "".)

This kind of convenience is exactly why many of our functions accept NULL
and often treat it similarly to "", although not necessarily the same. NULL
almost always means the absence of a value in Nautilus code. And there are
tons of places where we want to work with a string that might have an absent
value without lots of explicit checks.

    -- Darin