These markers had been used inconsistently. Furthermore the source code
had not been formatted automatically before 2020 at all, otherwise there
wouldn't have been any trailing whitespace left.
The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.
Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.
With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.
Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.
These blocks mostly consisted of redundant structure, following the same
#ifndef pattern over and over, with only minimal variation.
It's easier to maintain if the common structure is only written once and
encapsulated in a macro.
To avoid "defined but unused" warnings from GCC in the case where
MAKE_NATIVE is not defined, I had to add volatile. Adding
MAKE_ATTR_UNUSED alone would not preserve the rcsid variable in the
resulting binary.
The "at most" branch was never taken since all call sites in var.c only
ever need a substring, and the target buffer is not limited. Therefore
rename the function and make it simpler.
It's ok that bmake_strldup is defined as estrndup in case of USE_EMALLOC
since that function's implementation is compatible to the "copy
exactly", it just contains some extra null checks that will never match
since the variable values cannot (well, or should not) contain null
bytes. Theoretically they can, but the behavior then depends on the
exact implementation and is unreliable, therefore nobody does this.
After all, Makefiles are used for text processing, not for binary data.
Just in case the given str is not really a string.
The POSIX 2018 documentation on strndup does not specify as clearly as
possible whether s has to be a string or whether raw memory is
acceptable as well. It only indirectly calls the s parameter of strndup
a string.
with versions prefixed by MAKE_ATTR_* to avoid modifying the
implementation namespace. Make sure they are available in all places
using nonints.h to fix bootstrap on Linux.
rillig