Re: [Vala] Possible but in string.index_of, index_of_char and contains

[Thomas Olson <tolson stratagium net>]

On 10/16/2013 10:20 PM, Evan Nemerson wrote:
> On Thu, 2013-10-17 at 11:07 +0800, Nor Jaidi Tuah wrote:
> > On Wed, 2013-10-16 at 19:45 -0700, Evan Nemerson wrote:
> > > On Thu, 2013-10-17 at 09:19 +0800, Nor Jaidi Tuah wrote:
> > > > > "ABC".index_of_char('\x00'):  0
> > > > This looks like a bug. But why should
> > > > you want to search for \x00 ?
> > > string.index_of_char is basically a wrapper around g_utf8_strchr.  I
> > > guess g_utf8_strchr could return null if c==0, but it does feel a bit
> > > ridiculous.  If you feel strongly about it you can file a bug against
> > > glib.
> > I thought it should return -1.
> string.index_of_char is a wrapper which calls string.utf8_strchr.
> string.utf8_strchr is the binding for g_utf8_strchr.  g_utf8_strchr
> should probably return NULL (instead of a pointer to the beginning of
> the string), which would cause string.index_of_char to return -1.
>
> > But this is a very very very minor bug.
> > I can't think of a reason to search for \x00
> > (Any program searching for \0 in a string
> > must have a serious bug somewhere)
> > So, getting this fixed really gains nothing.
> Agreed.  I'd probably do a g_return_val_if_fail (c != 0, NULL) to make
> it clear that the request is nonsensical.
>
>
> -Evan

I was using a string to contain a set of char values that were 
considered part of a valid alphabet for an
encoding algorithm.  NULL was not part of the alphabet, but I was 
getting some false positives where
a NULL character within the input stream was being perceived as the 
first character in the valid
character list, which caused some problems.  It was in my testing to 
determine what was happening
that I discovered the "NULL == position 0" issue.  My initial thought is 
consistent with Nor in that I would
have expected -1 to be the answer or and index outside the length of the 
string (catching the NULL
terminator).  I agree that searching for a NULL char within a string is 
unusual and I can easily get around
the issue by using an char[] or uint8[], but I thought the irregularity 
when dealing with strings was
worth noting.  Neither array option has the same problem with using the 
"in" operator, but
does require the addition of "index_of" methods to determine ordinal 
position within the array.

Thanks for the feedback,

Tom