On Tue, Nov 24, 2020 at 05:16:03PM +0100, Fabian Wolff wrote: > Dear maintainer, > > consider the following warnings emitted by blhc (line breaks are mine; > see the attached "test.log" file for an input that reproduces this > problem): > > [snip]
Hello Fabian, thanks for the sample log to easily replicate the issue. > One could argue whether blhc should even consider lines like these, > because they do not actually contain any compiler calls; perhaps it > would be more sensible to delay the warnings to the actual compiler > calls that the recursive make or the script perform. However, it > doesn't hurt to be on the safe side and check calls like these, too. > > The problem is that the reportedly missing flags aren't missing at > all: The former call contains "-Wl,-z,relro" in both CFLAGS and > LDFLAGS; the latter call contains "-D_FORTIFY_SOURCE=2" in both CPP > and CPPFLAGS. > > So, why does blhc think that those flags are missing? blhc uses a few heuristics to detect lines with (possible) compiler commands to prevent false negatives. Lines containing `gcc` and similar are flagged. In this case the CC= environment variable triggers this. Then blhc looks for the actual build command and its flags. Here the quote after -D_FORTIFY_SOURCE=2 is the problem because blhc requires a space after each flag. I know this handling is not perfect but parsing arbitrary shell commands is difficult. I've just pushed a fix for the `make` case which is easily fixable without causing false negatives (all make commands are now simply ignored). In addition, I improved the line splitting so something like `make && gcc test.c` now correctly triggers a warning (in the past lines were split only on ";", now "&&" and "||" are also considered; I hope this won't cause too many false positives). However, the second command is more difficult to fix because it would require stripping all environment variables from each command. Although possible it would be quite slow and complex (escaping and nested quotes must be considered). I think in this case the simplest solution is to manually ignore the line with "blhc: ignore-line-regexp: REGEXP" in debian/rules. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
