Don't complain about using braces when they could be omitted, for
example:
if (condition) {
single_statement();
}
Another example:
if (condition) {
single_statement();
} else {
another_single_statement();
}
This is not something we would care about in code review either from
what I've seen and so it's probably just annoying for patch authors to
fix up.
Related: OS#5087
Change-Id: Ice08d5b88c683a59bacff999a1d6c07754663d39
Not necessarily followed in Osmocom code, as Daniel wrote:
> The lint complains about this break, I don't agree with it though.
> Without we're one (or two) refactors away from an unintended
> fall-through
Related: OS#5087
Change-Id: I3f106510953b0b1bf70c28ceb55a431c5c03854e
In Osmocom code, we have the following written in one line:
while (osmo_select_main_ctx(1) > 0);
This currently causes the following linter error:
ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
According to the linter, we should write it as follows:
while (osmo_select_main_ctx(1) > 0)
;
But this is not followed in Osmocom code, so let's ignore the check.
Related: OS#5087
Change-Id: Iaffe979b771c97c77edaf4aa0d232cb8939d1279
When running the linter on a patch with lots of files changed, and lots
of exclude files, this makes a big difference. On my machine, running an
osmo-iuh patch with 1580 files changed, and the high amount of asn1c
related excludes, the time for linting is reduced from 50s to 25s.
This should be acceptable, since typically we change only few files.
Change-Id: I6fb41dec25ecc1f2df7242ae041a8685a696c3fd
Does not make a noticable speed difference on a typical patch with few
changed files, but makes linting on big patches with ~1000 files and
lots of asn1c generated files in the repository significantly slower.
The next patch will optimize that case.
Change-Id: I7437d888b433fec8a444e4d7c285fff47d16c0c7
Add Osmocom specific check to forbid using strncpy() and strcpy().
Instead, osmo_strlcpy() or OSMO_STRLCPY_ARRAY() should be used.
Related: OS#5087
Related: https://lists.osmocom.org/pipermail/openbsc/2021-September/013538.html
Change-Id: I6fa96c8f3d15110dd3d3509faa593285a78f469e
According to a comment in checkpatch.pl, these should automatically be
ignored when LONG_LINE is ignored. However I found that it's still
complaining about LONG_LINE_COMMENT, so explicitly disable it.
Related: OS#5087
Change-Id: I7aed3bfbfcb0b9e2f1d743b111e8418846f031d2
Mentioning the file in itself is useful sometimes (e.g. when explaining
how to use a contrib script). So do not let the linter fail here.
Related: OS#5087
Change-Id: I151b97bc7f2fe83898c0598db54360807956993c
Pau has to remind me often that %d is used instead of %i in Osmocom
trees, so let's automate it.
Complain like this:
src/vty/command.c:3052: WARNING:PRINTF_I_OSMO: Use %d instead of %i
Related: OS#5087
Change-Id: I1a98326f1cbf4d2e0bb948558e5cd1726b0a9868
Don't complain that macros such as __packed should be used, which are
defined in the Linux kernel but not in libosmocore.
For example:
src/gsm/gsm0808.c:85: WARNING:PREFER_DEFINED_ATTRIBUTE_MACRO: Prefer __packed over __attribute__((packed))
Related: OS#5087
Change-Id: I2bf3b7d60e99cf91f7b619af54167a11cdfae8c6
Do not complain if indenting with exactly 6/7 spaces below (g)DEFUN(,
as it's often done in VTY-related code in Osmocom. This patch assumes
that if the line starts with 6/7 spaces and " or a word, it's probably
below DEFUN( or gDEFUN(. I've considered implementing a more accurate
check, but that would be too much effort (e.g. when more macros are
involved).
Other related macros, such as DEFUN_ATTR are longer. Indentation below
those should be done with one tab (+ spaces for padding), the linter
doesn't need to be adjusted for those.
Related: OS#5087
Change-Id: I0934b63a62500e7a3e09c753cc63aa331e580cc6
Don't complain with:
ERROR:SPACING: space prohibited after that '&&' (ctx:ExW)
in code similar to:
if (conn->conn->mode != MGCP_CONN_LOOPBACK
&& conn->conn->mode != MGCP_CONN_RECV_ONLY
&& !mgcp_rtp_end_remote_addr_available(&conn->end)) {
The check was supposed to complain about spaces if the && is used as
unary operator (to get the address of a goto label). But it's clearly
producing false positives in the Osmocom context with use as non-unary
operator, so remove this check.
Related: OS#5087
Related: 0d413866c7
Change-Id: I7ce79e6b291b3a3dab6587a589eeef0a0bc53de9
Prepare to run checkpatch on patches submitted to gerrit to point out
various linting errors automatically, such as { after functions not
placed on a new line, or common spelling errors.
Import version from 7e6cdd7f ("checkpatch: improve ALLOC_ARRAY_ARGS test")
of linux.git.
Related: OS#5087
Related: https://osmocom.org/projects/cellular-infrastructure/wiki/Linting
Change-Id: I58571a0409e79d88d37e8328f41a540a58cfb198