On 2/2/25 16:00, Tom Rini wrote:
On Sun, Feb 02, 2025 at 01:01:00PM +0100, Heinrich Schuchardt wrote:
On 1/20/25 21:52, Tom Rini wrote:
On Sun, Jan 05, 2025 at 11:46:14AM +0100, Heinrich Schuchardt wrote:
The setexpr.s command allows to concatenate two strings.
According to the description in doc/usage/cmd/setexpr.rst the parameters
value1 and value2 can be either direct values or pointers to a
memory location holding the values.
Unfortunately `setexpr.s <value1> + <value2>` fails if any of the values
is a direct value. $? is set to false.
* Add support for direct values in setexpr.s.
* Correct the unit test for "setexpr.s fred 0".
* Add a new unit test for "setexpr.s fred '1' + '3'" giving '13'.
Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
This causes ut_setexpr_setexpr_test_str to fail.
Hello Tom,
I am not able to reproduce this problem in Gitlab.
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/24424
Please, provide a link to the failure.
The three failures in:
https://source.denx.de/u-boot/u-boot/-/jobs/999497
were from that test. Do we have some problem lurking perhaps similar to
what Marek fixed in commit 082b41df8abd ("test/cmd/wget.c: Fix loadaddr
rewrite") ?
Hello Tom,
Thanks for the link.
With my patch
setexpr.s fred 0
is expected to succeed and allocate a string "0" that is assigned to
environment variable fred.
A few lines below Simon acknowledges that the assumption that replacing
an environment string by a string of same size does not change the value
of ut_check_free() does not hold true:
/*
* This fails in CI at present.
*
* ut_assertok(ut_check_delta(start_mem));
*/
I will update the patch accordingly.
@Simon:
In env_do_env_set() free() occurs after malloc(). Depending on the
current memory layout the free() may or may not result in merging of
chunks. So it is not expected that the available memory size stays the
same when replacing the value of an environment variable by a string of
the same size.
Best regards
Heinrich
