These types are explicitly allowed by GCC.
I'm not sure which of the flags -g and -p should be stronger. That is,
if both -g and -p are given, should 'unsigned char' be allowed as a
bit-field type since -g would allow it, or should it be warned about
since -p warns about it? For now, continue to warn about these.
The whole purpose of this test is to try the message about invalid
bit-field types in GCC mode. Therefore, use the default lint1-flags
that include -g.
Scoring by channel count makes sense when you are using hardware that
supports mono and stereo formats. However, if your hardware also supports
surround formats, defaulting to those might be confusing. So, don't
prefer them.
Problem reported and fix tested by tcmart14 with a 2015 model Macbook Pro.
Previously, the simplest way of getting the preprocessed translation
unit was to run lint with the additional flag -V, which outputs the
command line of the C preprocessor, among other things. That command
line does not include the proper quoting though, so it cannot be used
verbatim as a shell command if the command line contains spaces such as
in -Du64="unsigned long long".
In the common situation where lint is run via a Makefile, the option -V
had to be added in the Makefile itself since there is no make variable
for additional user-settable lint flags. This is not straight-forward
enough.
Adding another command line option for this purpose would reduce the
remaining namespace for options. Most of the 52 letters are already
used up.
To make this situation as simple as possible, preserve the output of the
C preprocessor depending on an environment variable.
The option -o must come before the first filename.
Now it is possible to lint kern_exec.c at least. The next failure is in
netbsd32_machdep.c:
netbsd32_machdep.c(395): error: illegal bit-field size: 255 [36]
That line in netbsd32_process_read_fpregs reads:
__CTASSERT(sizeof(*regs) == sizeof(struct save87));
This is probably a bug in lint. The struct save87 contains 3 uint16_t,
followed by a union containing a uint64_t, followed by a packed struct
with size 10. The combination of packed and padding is suspicious.
The syntax errors due to the __asm statements are now gone. The file
kern_exec.c only produces a few warnings now. But after running that
file through lint1, the main lint complains about wrong usage. This is
due to this call:
${LINT} ... -i $< -o $@
The main lint has never supported -o after the first filename, so it
complains. It would have been helpful if lint had given any hint as to
which option was invalid. Anyway, the next step is to reorder the
arguments. As it is now, the code can never have worked.
Due to the missing path, the following commands had failed:
$ cd src/sys/arch/amd64/compile/GENERIC
$ nbmake-amd64-lint kern_exec.ln
nbmake: don't know how to make kern/kern_exec.c. Stop
After fixing the path, "make kern_exec.ln" fails with:
sys/kern/kern_exec.c(65): error: syntax error '"' [249]
The affected line contains:
__KERNEL_RCSID(0, "...");
The macro __KERNEL_RCSID expands to __asm("some strings"). Since
KERNLINTFLAGS is missing the -g, lint does not recognize __asm as
keyword and tries to parse it as an identifier instead, expecting a
variable or function declaration.
on the descriptor won't block indefinitely if other thread is currently
blocked on the same kqueue in kevent(2)
done similarily to pipes and sockets, i.e. using flag on the potentially
shared kqueue structure hooked off file_t - this is somewhat suboptimal
if the application dup(2)ped the descriptor, but this should be rare
enough to not really matter
usually this causes the kevent(2) to end up returning EBADF since
on the syscall restart the descriptor is not there anymore; if
dup(2)ped the kevent(2) call can continue successfully if the closed
kqueue descriptor was other than the one used for the kevent(2)
call
PR kern/46248 by Julian Fagir
rillig