From owner-freebsd-current Mon Nov 10 05:42:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA01286 for current-outgoing; Mon, 10 Nov 1997 05:42:49 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA01266 for ; Mon, 10 Nov 1997 05:42:21 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA17110; Tue, 11 Nov 1997 00:39:48 +1100 Date: Tue, 11 Nov 1997 00:39:48 +1100 From: Bruce Evans Message-Id: <199711101339.AAA17110@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, Shimon@i-Connect.Net Subject: Re: LINT Errors Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >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 ). >../../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 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