BUG: fix incorrect strcmp implementation for unequal length strings

[ngoldbaum]

Followup for #25515, the result of strcmp shouldn't depend on the characters of the longer string for characters after the length of the shorter string

[mhvk]

Ah, so it was that part. But nicer realizing that after the end a string should be considered all 0, so the other one is always larger.

[lorentzenchr]

The logic seems sound now.

[seberg]

I am confused, wouldn't this make:

In [1]: "a" == "a\0"
Out[1]: False

Return True? For NumPy strings, this should be handled already earlier by the length, and for the new strings embedded 0 characters should be supported.

EDIT: Or I don't know maybe we need strcmp_padded for legacy strings...

[ngoldbaum]

I'm learning new things about numpy strings every day. For some reason I thought that this was True until now, but I'm clearly wrong:

In [1]: import numpy as np

In [2]: np.__version__
Out[2]: '1.26.3'

In [3]: np.str_("a") == np.str_("a\0")
Out[3]: False

The scalar repr doesn't include the trailing nulls, which I guess makes sense but definitely added to my confusion here:

In [4]: np.str_("a\0")
Out[4]: 'a'

In [5]: repr(np.str_("a\0")) == repr(np.str_("a"))
Out[5]: True

[ngoldbaum]

Although I guess the above is only true for scalars, for array elements trailing nulls are ignored in Numpy 1.26.3:

In [12]: np.array([np.str_("a\0")]) == np.array([np.str_("a")])
Out[12]: array([ True])

[seberg]

Just shows that scalars are broken... they should strip nulls on construction to not inherit the unicode behavior, I guess.

[seberg]

Thanks Nathan. Sorry, I was confused thinking about the new stringdtype for which the trailing 0 character handling would have been incorrect.

[ngoldbaum]

Pulling this in, we have a separate implementation for UTF-8 strings that doesn't need this strcmp implementation.