There is a suspicious condition in SuffUpdateTarget code that looks wrong
on the first sight. When removing it though, make allocates huge amounts
of memory. To stop freezing the whole machine in this situation, limit
the total memory.
The limit of 200000 has been determined experimentally on NetBSD 8.0
x86_64. With a limit of 100000, make wouldn't even start. 100 MB of
memory is really a lot for such a simple program that according to top(1)
only needs 8 MB. But 200 MB is still better than 5 GB.
Since the Makefile is used on other platforms as well, via the bmake
distribution, and since every operating system has its own list of ulimit
options, make this configurable.
The previous code with the extra boolean variable was a brain-twister
since the responsibility of freeing the memory was distributed over 3
different functions.
One notable thing is that there is no debug output when adding a
transformation rule like ".c.o", which means that these rules don't end
up in the global allTargets variable.
This may or may not be intentional. It seems not intentional since this
is one of the causes for the suff-rebuild test to behave unexpectedly.
As long as it is not clear why this test fails, it's better to have the
debug log available, both for reading it and for getting notified if
any behavior in this area changes.
It was unclear what the ellipsis referred to. It was meant to refer to
the function call Lst_Free, but that was not necessarily obvious to a
casual reader.
The "Removing suffix" is not covered by the current tests. It would be
best if that code were unreachable at all, since a reference count of -1
doesn't make sense.
The prefix "gs" came from a time when SuffScanTargets was called via
Lst_ForEach, passing it a struct GNodeSuff. The "gs" had just been the
abbreviation for "GNode + Suff", which was already non-expressive. On
top of that, the struct had a third field "r", also with an unclear name,
which was not even mentioned in the name of the struct.
For now, just remove the needless prefix since it has absolutely no
meaning anymore. Maybe it will become clear what the "r" was supposed to
mean, it could be some kind of "result".
Since revision 1.3, directive-export-gmake.mk takes care of handling this
case. Removing the "error" lines from the output of the tests only makes
the test harder to understand and may also hide future bugs.
The previous comment "List of sources" didn't tell anything about the
purpose of the variable, it was only useful before July 2020, when its
data type was still Lst, without any type information.
Having a global variable here seems pointless, but all the code about
suffix transformations is so tricky and not well covered by tests that I
don't dare to convert the global variable to a local variable in
Suff_FindDeps. The change itself would be trivial, but the hidden and
undocumented intentions of the original author probably aren't.
Patch and explanation taken from bsdimp:
https://bsdimp.blogspot.com/2020/08/a-35-year-old-bug-in-patch-found-in.htmlhttps://svnweb.freebsd.org/base?view=revision&revision=364291
Every version of patch since the first one posted to mod.sources in 1985 have
included a heuristic for coping with the state of email messaging at the
time. This heuristic would add up to 4 blank lines to a patch if it thought it
needed it. The trouble is, though this causes at least one bug.
The bug in my case is that if you have a context diff whose last hunk only
deletes 3 or fewer lines, then if you try to reverse apply it with -R, it will
fail. The reason for this is the heuristic builds an internal representation
that includes those blank lines. However, it should really replicate the lines
from the pattern lines line it would any other time, not assume they are blank
lines. Removing this heuristic will prevent patch from misapplying the lines
removed after applying a 'fuzz' factor to the previous blank line in the file. I
believe this will only affect 'new-style' 4.3BSD context diffs and not the
older-style 4.2BSD diffs and plain, non-context diffs. It won't affect any of
the newer formats, since they don't use the 'omitted' construct in the same way.
Since this heuristic was put into patch at a time when email / etc ate trailing
white space on a regular basis, and since it's clear that this heuristic is the
wrong thing to do at least some of the time, it's better to remove it
entirely. It's not been needed for maybe 20 years since patch files are not
usually corrupted. If there are a small number of patch files that would benefit
from this corruption fixing, those already-currupt patches can be fixed by the
addition of blank lines. I'd wager that no one will ever come to me with an
example of a once-working patch file that breaks with this change. However, I
have 2 patches from the first 195 patches to 2.11BSD that are affected by this
bug, suggesting that the relative frequency of the issue has changed
signficantly since the original heuristic was put into place.
Dash only accepts environment variables whose names follow the usual
naming conventions. (I didn't look up the exact details.) In
particular, it rejects environment variables whose names start or end
with spaces.
This would result in an empty output from grep, in which case the exit
status from the shell command is non-zero, thus make prints an error
about this. This error message should not appear in the test output, to
keep the test output the same for all platforms.
rillig