Several tests use CONFIG_SYS_MALLOC_LEN to test allocations that should
fail due to exceeding pool size. However, the actual malloc pool size is
TOTAL_MALLOC_LEN, which includes CONFIG_ENV_SIZE for boards that need to
store the environment in RAM. The extra space accommodates:
- the hash table allocated via calloc()
- strdup() calls for each environment variable key
- strdup() calls for each environment variable value
This is an estimate and typically consumes less than CONFIG_ENV_SIZE,
leaving more free space in the malloc pool than was reserved.
On qemu-x86_64, CONFIG_ENV_SIZE is 0x40000, making the actual pool
0x240000 bytes. Tests expecting malloc(CONFIG_SYS_MALLOC_LEN) to fail
might unexpectedly succeed since there's more space available.
Update all tests to use TOTAL_MALLOC_LEN to correctly reflect the actual
malloc pool size.
Co-developed-by: Claude <noreply@anthropic.com>
Unlike linked lists, it is inefficient to remove items from an alist,
particularly if it is large. If most items need to be removed, then the
time-complexity approaches O(n2).
Provide a way to do this efficiently, by working through the alist once
and copying elements down.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to empty the list without de-allocating any of
the memory used, e.g. when the list will be re-populated immediately
afterwards.
Add a new function for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some macros which permit easy iteration through an alist, similar to
those provided by the 'list' implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
In various places it is useful to have an array of structures, but allow
it to grow. In some cases we work around it by setting maximum number of
entries, using a Kconfig option. In other places we use a linked list,
which does not provide for random access and can complicate the code.
Introduce a new data structure, which is a variable-sized list of structs
each of the same, pre-set size. It provides O(1) access and is reasonably
efficient at expanding linearly, since it doubles in size when it runs out
of space.
Signed-off-by: Simon Glass <sjg@chromium.org>
