tree c105ee3e7716c3fa22ebe19885475c30da1dd4e5
parent c6cb41e1064c48e9d491fd5b3adc8c09a7bbc48c
author Rasmus Villemoes <rasmus.villemoes@prevas.dk> 1664960965 +0200
committer Tom Rini <trini@konsulko.com> 1666876208 -0400

lib: fix buggy strcmp and strncmp

There are two problems with both strcmp and strncmp:

(1) The C standard is clear that the contents should be compared as
"unsigned char":

  The sign of a nonzero value returned by the comparison functions
  memcmp, strcmp, and strncmp is determined by the sign of the
  difference between the values of the first pair of characters (both
  interpreted as unsigned char) that differ in the objects being
  compared.

(2) The difference between two char (or unsigned char) values can
range from -255 to +255; so that's (due to integer promotion) the
range of values we could get in the *cs-*ct expressions, but when that
is then shoe-horned into an 8-bit quantity the sign may of course
change.

The impact is somewhat limited by the way these functions
are used in practice:

- Most of the time, one is only interested in equality (or for
  strncmp, "starts with"), and the existing functions do correctly
  return 0 if and only if the strings are equal [for strncmp, up to
  the given bound].

- Also most of the time, the strings being compared only consist of
  ASCII characters, i.e. have values in the range [0, 127], and in
  that case it doesn't matter if they are interpreted as signed or
  unsigned char, and the possible difference range is bounded to
  [-127, 127] which does fit the signed char.

For size, one could implement strcmp() in terms of strncmp() - just
make it "return strncmp(a, b, (size_t)-1);". However, performance of
strcmp() does matter somewhat, since it is used all over when parsing
and matching DT nodes and properties, so let's find some other place
to save those ~30 bytes.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>