u-boot.git/lib/string.c, branch v2024.07-rc2

Revert "lib: string: Fix strlcpy return value", fix callers

2023-08-08T21:05:43+00:00

Both the Linux kernel and libbsd agree that strlcpy() should always
return strlen(src) and not include the NUL termination. The incorrect
U-Boot implementation makes it impossible to check the return value for
truncation, and breaks code written with the usual implementation in
mind (for example, fdtdec_add_reserved_memory() was subtly broken).

I reviewed all callers of strlcpy() and strlcat() and fixed them
according to my understanding of the intended function.

This reverts commit d3358ecc54be0bc3b4dd11f7a63eab0a2842f772 and adds
related fixes.

Fixes: d3358ecc54be ("lib: string: Fix strlcpy return value")
Signed-off-by: Matthias Schiffer 
Reviewed-by: Simon Glass 
Reviewed-by: Sean Anderson

lib: fix buggy strcmp and strncmp

2022-10-27T13:10:08+00:00

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

lib: Add memdup()

2021-10-08T19:53:26+00:00

Add a function to duplicate a memory region, a little like strdup().

Signed-off-by: Simon Glass

string: make memcpy(), memset(), memcmp() and memmove() visible for LTO

2021-05-24T18:21:30+00:00

It seems that sometimes (happening on ARM64, for example with
turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
names of some functions, for example lib/string.c's memcpy() function to
memcpy.isra.0.

This is a problem however when GCC for a code such as this:
	struct some_struct *info = get_some_struct();
	struct some struct tmpinfo;
	tmpinfo = *info;
emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.

This then results in the following linking error:
  .../lz4.c:93: undefined reference to `memcpy'
  .../uuid.c:206: more undefined references to `memcpy' follow

GCC's documentation says this about -nodefaultlibs option:
  The compiler may generate calls to "memcmp", "memset", "memcpy" and
  "memmove".  These entries are usually resolved by entries in libc.
  These entry points should be supplied through some other mechanism
  when this option is specified.

Make these functions visible by using the __used macro to avoid this
error.

Signed-off-by: Marek Behún 
Reviewed-by: Simon Glass

lib: string: Implement strlcat

2021-04-12T21:44:55+00:00

This introduces strlcat, which provides a safer interface than strncat. It
never copies more than its size bytes, including the terminating nul. In
addition, it never reads past dest[size - 1], even if dest is not
nul-terminated.

This also removes the stub for dwc3 now that we have a proper
implementation.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass

lib: string: Fix strlcpy return value

2021-04-12T21:44:55+00:00

strlcpy should always return the number of bytes copied. We were
accidentally missing the nul-terminator. We also always used to return a
non-zero value, even if we did not actually copy anything.

Fixes: 23cd138503 ("Integrate USB gadget layer and USB CDC driver layer")

Signed-off-by: Sean Anderson

string: Use memcpy() within memmove() when we can

2021-01-16T19:49:09+00:00

A common use of memmove() can be handled by memcpy(). Also memcpy()
includes an optimization for large sizes: it copies a word at a time. So
we can get a speed-up by calling memcpy() to handle our move in this case.

Update memmove() to call also memcpy() if the source don't overlap
the destination (src + count <= dest).

Signed-off-by: Patrick Delaunay

string: Allow arch override of strndup() also

2020-02-06T02:33:46+00:00

At present architectures can override strdup() but not strndup(). Use
the same option for both.

Signed-off-by: Simon Glass

lib: Implement strndup()

2019-06-05T16:16:32+00:00

Signed-off-by: Thierry Reding 
Signed-off-by: Tom Warren

string: Include the config header

2018-11-21T02:14:22+00:00

At present the config header is not included in this file, but it does use
a CONFIG option. Fix it.

Signed-off-by: Simon Glass