| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
|
|
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>
|
|
Add a function to duplicate a memory region, a little like strdup().
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
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 <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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 <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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 <seanga2@gmail.com>
|
|
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 <patrick.delaunay@foss.st.com>
|
|
At present architectures can override strdup() but not strndup(). Use
the same option for both.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
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 <sjg@chromium.org>
|
|
Add an implementation of strcspn() which returns the number of initial
characters that do not match any in a rejection list.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This functions works like strchr() but returns the end of the string if
the character is not found. Add an implementation of this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
A common use of memmove() can be handled by memcpy(). Also memcpy()
includes an optimisation 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 memcpy() if the destination is before the source.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Most of the time the optimised memset() is what we want. For extreme
situations such as TPL it may be too large. For example on the 'rock'
board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and
the rodata bug, this patch is enough to reduce the TPL image below the
limit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
|
|
Since bcopy() is no longer used, delete all remaining references to
it.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
|
|
Move strlcpy() definition from drivers/usb/gadget/ether.c to
lib/string.c because it is a very useful function.
Let's add the prototype to include/linux/string.h too.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
This patch is essentially an update of u-boot MTD subsystem to
the state of Linux-3.7.1 with exclusion of some bits:
- the update is concentrated on NAND, no onenand or CFI/NOR/SPI
flashes interfaces are updated EXCEPT for API changes.
- new large NAND chips support is there, though some updates
have got in Linux-3.8.-rc1, (which will follow on top of this patch).
To produce this update I used tag v3.7.1 of linux-stable repository.
The update was made using application of relevant patches,
with changes relevant to U-Boot-only stuff sticked together
to keep bisectability. Then all changes were grouped together
to this patch.
Signed-off-by: Sergey Lapin <slapin@ossfans.org>
[scottwood@freescale.com: some eccstrength and build fixes]
Signed-off-by: Scott Wood <scottwood@freescale.com>
|
|
isspace() and strim() are not in the typical user-mode string.h, so
put them in a separate compilation unit so that they can be built into
tools that need them independent of the other common string functions.
This allows code shared by u-boot and the linux user-mode tools to link.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
strncasecmp() is present as strnicmp() but disabled. Make it available
and define strcasecmp() also. There is a only a small performance penalty
to having strcasecmp() call strncasecmp(), so do this instead of a
standalone function, to save code space.
Update the prototype in arch-specific headers as needed to avoid warnings.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
[backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe]
This is part of the synchronization with the nand driver to the
Linux 3.0 state.
Signed-off-by: Christian Hitz <christian.hitz@aizo.com>
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
|
|
In some cases (e.g. bootm with a elf payload which is already at the right
position) there is a in place copy of data to the same address. Catching this
saves some ms while booting.
Signed-off-by: Matthias Weisser <weisserm@arcor.de>
|
|
Now that the other architecture-specific lib directories have been
moved out of the top-level directory there's not much reason to have the
'_generic' suffix on the common lib directory.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
|
