On Wed, Oct 05, 2022 at 11:09:25AM +0200, Rasmus Villemoes wrote:
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
Applied to u-boot/master, thanks!