Date: Thu, 11 Feb 2016 08:27:19 -0800 From: Rui Paulo <rpaulo@me.com> To: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org Cc: bde@freebsd.org Subject: Re: Goodbye for lint(1) Message-ID: <1455208039.2282.1.camel@me.com> In-Reply-To: <20160211112038.GQ91220@kib.kiev.ua> References: <20160211112038.GQ91220@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2016-02-11 at 13:20 +0200, Konstantin Belousov wrote: > I believe the time has come to remove lint and its libraries from the > system. I did some manipulations with the mcontext_t/ucontext_t to > make > us more POSIX-compatible, and found several things about lint(1) > which > cause serious questions about tool usefulness. > > My main point is that the lint processing starts with "cc -E -undef" > producing the preprocessed source of the linted file or library. The > -undef switch removes (almost) all predefined symbols, most > importantly, > the __<arch>__ and __LP64__ and its variants are dropped. > > Due to this, for the whole 10.x lifetime, since the merge of the i386 > and amd64 MD includes, lint cannot ever correctly work on amd64. The > same should be true for powerpc, and there headers are more unified > and > the effect is less enchanting. Even on i386, since headers other than > _type.h tend to use #ifdef __i386__/#endif and #ifdef > __amd64__/#endif, > lint cannot see a lot of system. > > Nobody complained for 3 (?) years about the tool which clearly > misfunctioned. I propose to kill it as unused. Modern compilers do > much > better job at diagnosing inconsistencies supposedly detected (but > really > not) by lint. Yes, it should've been removed years ago... -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1455208039.2282.1.camel>