Date: Tue, 11 Nov 1997 00:39:48 +1100 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@FreeBSD.ORG, Shimon@i-Connect.Net Subject: Re: LINT Errors Message-ID: <199711101339.AAA17110@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>So, here is another batch of complaints (GCC, not me; I am not complaining
>:-)
>
>../../dev/ppbus/vpo.c: In function `vpointr':
>../../dev/ppbus/vpo.c:67: warning: can't inline call to `vpoio_do_scsi'
>../../dev/ppbus/vpo.c:283: warning: called from here
>
>[ I am getting plenty of these lately. Dunno why :-( ]
Someone turned on the warning for bogus inlines.
>../../kern/kern_malloc.c: In function `malloc':
>../../kern/kern_malloc.c:136: warning: passing arg 3 of `tsleep' discards
>`const' from pointer target type
>../../kern/kern_malloc.c:198: warning: assignment discards `const' from
>pointer target type
The wmesg arg to tsleep(), and p_wmesg in `struct proc' should have type
`const char *' instead of `char *'. Fixing this will probably cause more
warnings about discarding `const'. It was fixed in FreeBSD-1.1.5.
>../../kern/kern_opt.c:44: warning: #warning "obsolete option GATEWAY - use
>`sysctl -w net.inet.ip.forwarding=1'"
>
>[ Should i do as it says? ]
Only for non-LINT kernel config files that have a bogus GATEWAY option.
Someone should arrange for testing of the warnings using LINT to not
cause any warnings.
>../../miscfs/umapfs/umap_subr.c: In function `umap_mapids':
>../../miscfs/umapfs/umap_subr.c:366: warning: passing arg 2 of
>`umap_findid' from incompatible pointer type
>../../miscfs/umapfs/umap_subr.c:392: warning: passing arg 2 of
>`umap_findid' from incompatible pointer type
>
>[ Could be nothing, could be a bug ]
There is a minor problem involving confusing the address of an array
with the address of the first element in the array. The default
conversion doesn't work so well for multidimensional arrays.
>../../pccard/pccard.c: In function `unregister_device_interrupt':
>../../pccard/pccard.c:313: warning: implicit declaration of function
>`INTRDIS'
>../../pccard/pccard.c: In function `pccard_alloc_intr':
>../../pccard/pccard.c:497: warning: implicit declaration of function
>`INTREN'
>
>[ ??? ]
INTREN() and INTRDIS() are declared in the wrong place for the SMP
case. They should be declared in icu.h in all cases for compatibility.
>../../pci/if_vx_pci.c: In function `vx_pci_attach':
>../../pci/if_vx_pci.c:129: warning: passing arg 2 of `pci_map_int' from
>incompatible pointer type
>
>[ I remember why this is so, but not why it cannot be cast to shut GCC up ]
Casting would only hide the problem. I try to avoid function pointer
casts except when a correct fix is impractical. There are about 1000
hidden problems for syscall and vop functions :-(.
>../../ufs/lfs/lfs_segment.c: In function `lfs_vunref':
>../../ufs/lfs/lfs_segment.c:1232: warning: nested extern declaration of
>`vnode_free_list_slock'
>../../ufs/lfs/lfs_segment.c:1233: warning: nested extern declaration of
>`vnode_free_list'
>
>[ I do not really know what it means. Looks fine to me ]
The variables are declared in the wrong place (not in <sys/vnode.h>).
>../../i386/eisa/eisaconf.c: In function `eisa_reg_intr':
>../../i386/eisa/eisaconf.c:428: warning: passing arg 3 of `intr_create'
>from incompatible pointer type
>
>[ This is the cmplement of the PCI complaint. See there... ]
See above.
>../../i386/i386/db_interface.c: In function `kdb_trap':
>../../i386/i386/db_interface.c:73: warning: variable `ddb_mode' might be
>clobbered by `longjmp' or `vfork'
>
>[ Oh, really? ]
Possibly a real bug. It depends on the implementation of setjmp() and
the flow of control in the function.
>../../i386/i386/sys_machdep.c: In function `i386_get_ioperm':
>../../i386/i386/sys_machdep.c:225: warning: `i' might be used uninitialized
>in this function
A real bug.
>[ I routinely initialize these to zero ]
This would just hide the bug. I routinely complain about routine
initializations :-).
>../../i386/isa/if_el.c: In function `el_attach':
>../../i386/isa/if_el.c:86: warning: can't inline call to `el_hardreset'
>../../i386/isa/if_el.c:169: warning: called from here
>../../i386/isa/if_el.c: In function `elintr':
>../../i386/isa/if_el.c:84: warning: can't inline call to `elread'
>../../i386/isa/if_el.c:508: warning: called from here
>
>I already asked why these happen for the last week or so ]
See above.
>../../i386/isa/if_wl.c: In function `wl_cache_store':
>../../i386/isa/if_wl.c:2571: warning: `ip' might be used uninitialized in
>this function
No problem in practice. `ip' is only used in the (ipflag != 0) case,
and it is initialized in that case, but the flow of control is too
complicated for the compiler to see this. Since the flow of control is
not very complicated and ip is a pointer, routine initialization to 0
would not be wrong. However, since mtod() is just a cast, non-routine
initialization to the (ipflag != 0) value in all cases would be better
(the initialization takes about the same time as initialization to 0,
and not testing ipflag saves time).
>../../i386/isa/intr_machdep.c:80: warning: `AUTO_EOI_1' redefined
>opt_auto_eoi.h:1: warning: this is the location of the previous definition
AUTO_EOI_1 is forced for the SMP case. LINT sets AUTO_EOI_1 too, and
there is a conflict because the SMP forcing sloppily defines AUTO_EOI_1
as <nothing> while opt_auto_eio.h defines it as 1. This is a common
bug for -DFOO in Makefiles vs `#define FOO' in programs.
>[ Should the LINT option be removed, or should the define here be
> conditional? ]
The SMP maintainers should maintain LINT.
>../../i386/isa/pnp.c: In function `config_pnp_device':
>../../i386/isa/pnp.c:425: warning: implicit declaration of function `INTREN'
See above.
>../../i386/isa/pnp.c:343: warning: `name' might be used uninitialized in
>this function
>
>[ ??? ]
I haven't investigated.
>../../i386/isa/scd.c: In function `scd_probe':
>../../i386/isa/scd.c:151: warning: can't inline call to `write_control'
>../../i386/isa/scd.c:702: warning: called from here
See above.
>{ Some sound warnings were already reported tonight }
I haven't investigated most of the recently introduced warnings.
>...
>../../i386/isa/sound/uart6850.c: In function `poll_uart6850':
>../../i386/isa/sound/uart6850.c:113: `timeout_func_t' undeclared (first use
>this function)
>../../i386/isa/sound/uart6850.c:113: (Each undeclared identifier is
>reported only once
>../../i386/isa/sound/uart6850.c:113: for each function it appears in.)
>../../i386/isa/sound/uart6850.c:113: parse error before `poll_uart6850'
>*** Error code 1
Someone blew away previous cleanups.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711101339.AAA17110>