On 04/10/2022 01.49, Simon Glass wrote: > On Mon, 3 Oct 2022 at 03:03, Rasmus Villemoes > <rasmus.villem...@prevas.dk> wrote: >> >> Matching anything that just happens to have the sought-for label as a >> prefix is wrong. For example, if the board designer has designated 10 >> lines for debug purposes, named "debug1" through "debug10", and we are >> looking up "debug1", if debug10 happens to be met first during the >> iteration we'd wrongly return that. >> >> In theory, this can break existing users that could rely on this >> quirk, but OTOH keeping the current broken semantics can cause a lot >> of grief for people hitting this in the future and not understanding >> why they don't find the line they expect. Considering how few in-tree >> defconfigs currently set DM_GPIO_LOOKUP_LABEL (ignoring sandbox, only >> four "real" boards), let's fix it before the use becomes more >> widespread. >> >> Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk> >> --- >> drivers/gpio/gpio-uclass.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) > > Reviewed-by: Simon Glass <s...@chromium.org> > > It seems like we need a one-sided strncmp(): > > int strncmp(const char *match, const char *str, int max_len_of_str)
Eh, could you spell out what the semantics of that one would be? I can't think of anything that would differ from actual strncmp(). for (i = 0; i < m; ++i) { if (a[i] != b[i]) return a[i] - b[i]; if (!a[i]) break; } return 0; And why would we want anything other than actual string equality here? Oh, and now that I look at lib/string.c, both the generic strcmp() and strncmp() are broken. They correctly distinguish equality/inequality (up to the given bound), but they don't compare strings correctly, for several reasons. Sigh. Patch coming later. Rasmus