Whenever a string expansion is constructed by plumber (either when parsing a ruleset or matching a rule), a fixed buffer is used to build the resulting string in expand().
Generally, the output is grown one character at a time except for when a variable substitution is encountered, in which case the value of the variable is first prepared via dollar() and then appended to the buffer.
There are checks for buffer exhaustion in both cases (in the loop condition and prior to appending variable’s content), but it is treated differently—and without any errors being reported either way. In the former case, the result is silently truncated; in the latter case, for a reason that is not clear to me, the string string-too-long is returned instead (with none of the callers checking for it).
This inconsistency does not seem to be justified and should perhaps be fixed by choosing a single reasonable behavior as a reaction to both encounters of buffer exhaustion.
Additionally, although 4 KiB is probably enough for this buffer and hence it is not very likely for one to run out of it in practice, in my opinion, it would be better nevertheless to report it as an error, instead of silently proceeding with a stub or an error message as the resulting expansion.
Whenever a string expansion is constructed by plumber (either when parsing a ruleset or matching a rule), a fixed buffer is used to build the resulting string in
expand()
.Generally, the output is grown one character at a time except for when a variable substitution is encountered, in which case the value of the variable is first prepared via
dollar()
and then appended to the buffer.There are checks for buffer exhaustion in both cases (in the loop condition and prior to appending variable’s content), but it is treated differently—and without any errors being reported either way. In the former case, the result is silently truncated; in the latter case, for a reason that is not clear to me, the string
string-too-long
is returned instead (with none of the callers checking for it).This inconsistency does not seem to be justified and should perhaps be fixed by choosing a single reasonable behavior as a reaction to both encounters of buffer exhaustion.
Additionally, although 4 KiB is probably enough for this buffer and hence it is not very likely for one to run out of it in practice, in my opinion, it would be better nevertheless to report it as an error, instead of silently proceeding with a stub or an error message as the resulting expansion.