Writing *(p+1) is needlessly confusing, even though it adds a little
symmetry between *p and *(p+1). Still, one of these expressions has
parentheses, the other doesn't, which breaks the symmetry.
Wrap overly long code line.
It's confusing to refer to the digits after the backslash once with
index 0 to 2, and the other time with index 1 to 3.
Before, '\b' was interpreted as a simple 'b', which is confusing for C
programmers. Same for '\a'. There is absolutely no reason to escape
letters, so fail early in these cases.
The '\h' in the test addchstr was obviously a typo that was easy to
detect, if only the compiler had been strict enough from the very
beginning.
The code is wider than 80 characters, same as the code that parses octal
escape sequences a few lines above it. This code will be refactored to
use less indentation in a follow-up commit.
indent cannot handle line-end comments.
The indent test suite requires each test file to have both a NetBSD and
a FreeBSD RCS ID. If the FreeBSD RCS ID is missing, the test will
silently pass since in that case, an empty file is compared with an
empty file. See the /start/,/end/ operator in t_indent.sh.
It is possible that the type name 'array[unknown_size]' may spill into
the user-visible diagnostics. The current test suite does not cover
such a case. Anyway, saying 'array[unknown_size]' is still better than
saying 'array[0]', which would be misleading.
By listing the expected diagnostics directly at the code that triggers
the diagnostics, it is easier to cross-check whether the diagnostics
make sense.
No functional change to lint itself.
Several C99 tests do not actually test C99 features but instead GCC
features. All these tests should be double-checked again.
In some other tests, split the initializers into more lines, which makes
it easier to read the debug log corresponding to these tests. This will
be necessary for reworking the initializer code to actually conform to
C99.
It's too easy to forget one of them when adding or removing some lines.
This would make it more difficult to locate the lines referenced in the
error messages.
Right now, this variant of the popular macro pattern is flagged as
needing a /*CONSTCOND*/ annotation. As with 'do { ... } while (0)',
there is nothing wrong with this pattern, therefore there should be no
warning.
This is a preparation for allowing 'do { ... } while (false)', in
addition to the commonly used 'do { ... } while (0)', without declaring
the controlling expression /*CONSTCOND*/.
The intention of the getopt check was to analyze only those while loops
whose condition consists of the usual getopt call. For all other while
loops, ck.while_level was intended to stay at 0.
This was not the case in ckgetopt.c 1.2 and has been fixed in ckgetopt.c
1.3. The code did not document the intended invariants though, which it
should have done. This will be done in a follow-up commit.
Add a sh ATF test to demonstrate a bug in the way that \0 characters
are dropped from scripts. This test will eventually be extended to
test other potential sh script input related issues.
When initially committed, this test should fail. It should succeed
when the fix for the PR is committed (soon).
Nb: this tests only the \0 related issues from the PR, the MSAN
detected uninitialised variable (struct field) can only be detected
by MSAN, as it has no visible impact on the operation of the shell
when running on any real (or even emulated) hardware.
(It will, however, also be fixed).
The previous code only errored out if a write failed completely. If it
was partially written, the program continued without writing the rest of
it.
Extract the common code into a few functions that write raw data to the
parent process.
christos