Re: Rationale for change in behavior of g_strsplit when passed empty string?

[Owen Taylor <otaylor redhat com>]

Joel Becker <jlbec evilplan org> writes:

> On Mon, Jul 16, 2001 at 08:17:30PM -0400, Owen Taylor wrote:
> > 
> > The _right_ behavior is a tricky question. Logic says:
> > Empty elements are allowed internally:
> > 
> >     g_strsplit ("a:b:c")  => "a", "b", "c"
> >     g_strsplit ("a::c")  => "a", "", "c"
> > 
> > So, if we we treat empty elements as valid, we can't treat "" as meaning
> > an empty list. 
> > 
> >     g_strsplit ("b")  => "b"
> >     g_strsplit ("")  => ""
> > 
> > But practicality says there should be _some_ way of representing an
> > empty list.
> 
> 	I've found the most annoying thing about strsplit() to me is the
> boilerplate
> 
> if ((strv == NULL) || (strv[0] == NULL))
> 
> 	as a method to check if the split was on an empty string.

Wait ... unless you have no idea whether you are using GLib-1.2 or
GLib-1.3, the || makes no sense. In either case it is deterministic.

> strv[0][0] == '\0' meant an empty leading field.  With the new 1.3
> behavior I need to check all my code ;-).  Up until now my assumption
> has been that strv[0] == "" and strv[1] == NULL means that the string
> was ":" for a delimiter of ":".  This fails to work under the new code
> and probably has implications for anyone parsing a known delimited
> field (where escaping isn't an issue).
> 	I'm not sure it is such a big deal.  Just another two checks to
> type:
> 
> if ((strv == NULL) || (strv[0] == NULL) ||
>     ((strv[0][0] == '\0') && (strv[1] == NULL)))
> 
> 	or somesuch.  Maybe it is easier.  But I don't know there is a
> big, good reason for adding it.

OK, I'm lost. If I wanted to check if the string I was splitting was ":",
I think I'd use strcmp (string, ":") == 0   ;-)

Maybe you could give a real-world example of where you do these types
of checks? I don't think I've been tempted to do anything like this
ever.

Regards,
                                                Owen