I'm interested in fixing them. A few of these are silly, and maybe even
wasteful. E.g. E_STATIC_UNUSED points to things that are just wasting
kernel memory.
A few others, E_PTR_DIFF_OVERFLOW are tricky, but may point to actual
_errors_ in the code.
The worst offender, by far, is of course E_BAD_PTR_CAST_ALIGN, which is
a real pain in the neck to fix. I suspect a lot of those are the result
of things that _have_ to be done this way to meet API specifications.
All that said, I've not run lint on a full kernel build for a very, very
long time (since I left Sun.)
-- Garrett
James Carlson wrote:
> Meem and I have been talking on and off about reducing the number of
> -erroff directives in $SRC/uts/Makefile.uts. We both feel that
> quieting down lint is the wrong direction to go, as it all too often
> papers over real problems in the code that need to be fixed.
>
> For this reason, I filed and fixed 6219031 last year. That hauled out
> the trivial ones, but there still seems to be some low-hanging fruit
> available. I've rerun my lint checking on a recent Nevada build, and
> here's what I find:
>
> E_BAD_PTR_CAST_ALIGN s 8035 x 6329
> E_SUPPRESSION_DIRECTIVE_UNUSED s 251 x 214
> E_SUSPICIOUS_COMPARISON s 593 x 514
> E_INVALID_ANNOTATION_NAME s 17 x 13
> E_STATIC_UNUSED s 364 x 315
> E_PTRDIFF_OVERFLOW s 2657 x 2315
> E_ASSIGN_NARROW_CONV s 1459 x 1313
> E_CONST_TRUNCATED_BY_ASSIGN s 44 x 0
> E_NAME_MULTIPLY_DEF2 s 0 x 91
>
> The "s" entries are for SPARC, the "x" entries for x86, and each shows
> the number of occurrences of warnings with that tag. That's with all
> of the LINTTAGS commented out of $SRC/uts/Makefile.uts and
> $SRC/uts/i86pc/Makefile. (I haven't tried looking at the
> "-erroff=%all" inside acpcia.) (Attached is a copy of the homely
> shell script that produced that report.)
>
> Is anyone else here looking at the lint problem? Anyone interested in
> doing some more in-depth analysis or just plain fixing problems?
>
> Obviously, more can be done. If we ever get to the point where the
> code is completely clean, we might want to consider turning up the
> -Nlevel value, as the default almost completely ignores flow analysis.
> That'll give us plenty to chew on. ;-}
>
>
> ------------------------------------------------------------------------
>
> #!/bin/sh
>
> getlatestlog()
> {
> arch=$1
> shift
>
> for ws
> do
> if [ -d $ws/proto/root_$arch ]; then
> echo $ws/log/`/bin/ls -1 $ws/log | sort -r | head
> -1`/mail_msg
> return
> fi
> done
> echo cannot find log file for $arch >&2
> exit 1
> }
>
> c=`workspace children`
> s=`getlatestlog sparc $c` || exit 1
> x=`getlatestlog i386 $c` || exit 1
>
> sed -n '/^#.*LINTTAG/s/.*erroff=//p;/^#.*LINTFLAG/s/.*erroff=//p' \
> `wx list` |
> while read tag; do
> printf "%-32s s %5d x %5d\n" $tag `grep $tag $s | wc -l` `grep $tag $x
> | wc -l`
> done
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
