Re: unnecessary assertions in g_strsplit and g_strjoinv



On Tue, 2004-02-24 at 12:11, Bill Haneman wrote:
> Owen Taylor wrote:
> > 
> > On Tue, 2004-02-24 at 09:48, Bill Haneman wrote:
> > > g_strsplit and g_strjoinv now contain assertions that the string to split or strings to join are non-NULL.
> > >
> > > It's not clear to me that this is necessary; surely glib should check for NULL, but the semantics
> > > of splitting a NULL string needn't be ambiguous.   As it stands now, glib does the assertion
> > > checks, but requiring the client to do so means that all clients must test 'string' and
> > > 'str_array', before calling g_strsplit and strjoinv, respectively.
> > >
> > > Removing the assertions would reduce code size since all the glib string routine clients in the
> > > desktop could omit the checks (as some already do :-P ).
> > >
> > > I think this makes sense - note also that the requirement for the args of g_strsplit and g_strjoinv to
> > > be non-NULL is not documented.
> > 
> > No GLib string functions accept NULL, these functions certainly weren't
> > meant to be any different. What would it mean? NULL is not, never, the
> > same as "".
> > 
> > If people were commonly calling these functions with NULL and that had
> > some "reasonable" behavior, then we might have to preserve that for
> > compatibility. But it would be very much something forced by a past
> > screwup, not the way we would do it normally.
> 
> There's a lot of code that's now spewing glib warnings about this
> now, whereas there were no warnings previously (asserts were added
> in 2.3+ I think).  Behavior has not changed otherwise.  So I believe
> that your condition (above) is actually the current situation.

Could we get concrete examples?

I want to distinguish "code that was obviously buggy that just sort of
happened to work" from "code that is reasonable with the wrong
assumption of the behavior of g_strsplit".

Thanks,
						Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]