On Sun, Jan 3, 2016 at 3:31 AM, Ben Wiederhake wrote: > - flawfinder yields too many results to be practical (~ 2460 lines). This is > mostly due to libtgl being written in a style that uses static arrays for > everything, including parsing and output.
I've been thinking of making the default for c-a-t-t to limit output of checks by default, probably to around 10 lines. > - The output of "POFileSpell" seems to depend on the local dictionaries. It > seems to flag every word in every language I don't speak. (~ 1640 lines) This is correct, you obviously need to install the relevant dictionaries for it to be useful. > - i18nspector and Transifex (the service we use for our translation) heavily > disagree about how a po-file should look like, and how Russion plurals > work(?!). Jakub discussed this. > - include-what-you-use Is completely useless: It doesn't recognize > <stddef.h>, although it is installed and appears in the reference: > http://en.cppreference.com/w/c/header > It also recommends to do a lot of silly things, such as including struct > declarations in .c files. (~ 2820 lines) Jakub explained this. > - The following check complains loudly about plurals: > "find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check > --check-compatibility --check-accelerators --output-file=/dev/null {} \;" > I'm not sure what to do with that information. We want correct plural > support, so this won't change. Jakub explained this. I plan to have some sort of verbosity level thing in c-a-t-t, less verbosity would turn off --check-compatibility for this check I guess. > - "suspicious-source" works like a charm. It runs in a fraction of a second, > and outputs only a single line: "./tg-server.tglpub" > That's absolutely correct! I like that program. (I'm not complaining, I'm > admiring the program. The file ./tg-server.tglpub is clearly documented in > the README.md, including a link to a side-project with the sole purpose of > reproducibly generating this single file for public sources.) Hmm, are you sure? pabs@chianamo ~/telegram-purple-1.2.3 $ grep tglpub README.md pabs@chianamo ~/telegram-purple-1.2.3 $ After reading the source code I see that it is some sort of public key. > - The "Please add some upstream metadata" warning triggers. Since this is > not a scientific project, and there won't be any doi-references, I'm going > to ignore the warning. However, I'm going to use this to ask: Why is that a > warning? Why not include it in the build scripts of the deb-science > packaging team instead? The upstream metadata stuff has nothing to do with science apart from being initiated by the science team. Just include the parts that apply to this package. I don't understand why so many people have this misconception. > - The problem of bashisms relates to the program checkbashism, like Not sure I understood this. > incompatibilities between make-implementations to checkgmakeism, a program > I'd like to see being written. I made up the name. I have no idea how to do > that. So far, we did it by trial and error, and change something whenever a > user complains. AFAIK, by now we only support gmake, due to the use of > "ifdef", which should be ".ifdef" in bsd-make: > https://github.com/majn/telegram-purple/issues/137#issuecomment-167970054 That would be a good check to have but for now I don't know of any implementation or anyone interested in working on such a thing. > Sorry for the wall of text, but you *did* ask for it :P I did :) One goal of c-a-t-t is to expose more people to the tools, eventually leading to better tools :) > Btw: I'm naturally subscribed to the bug. And because you address your mails > to me, too, I receive them twice :P Apologies, the default in the Debian BTS is to not subscribe submitters and I can't assume that you are on debian-mentors, so I CCed you. -- bye, pabs https://wiki.debian.org/PaulWise
