From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id o92AAGQ2023792 for ; Sat, 2 Oct 2010 06:10:17 -0400 (EDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 3B96A157AB6 for ; Sat, 2 Oct 2010 12:10:11 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id UAJhBcwCm+FL for ; Sat, 2 Oct 2010 12:10:09 +0200 (CEST) X-KTH-Auth: kristaps [85.8.60.161] X-KTH-mail-from: kristaps@bsd.lv X-KTH-rcpt-to: tech@mdocml.bsd.lv Received: from lappy.cust.alltele.se (h85-8-60-161.dynamic.se.alltele.net [85.8.60.161]) by smtp-1.sys.kth.se (Postfix) with ESMTP id B9BCC157AB5 for ; Sat, 2 Oct 2010 12:10:09 +0200 (CEST) Message-ID: <4CA70518.6050003@bsd.lv> Date: Sat, 02 Oct 2010 12:10:32 +0200 From: Kristaps Dzonsons User-Agent: Thunderbird 2.0.0.23 (X11/20100318) X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv Subject: Re: term.c and lint References: <4C9F1241.9040706@hhs.se> <20100926172709.GC3502@iris.usta.de> <4CA061EC.1070006@bsd.lv> <20101001223742.GD17696@iris.usta.de> In-Reply-To: <20101001223742.GD17696@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> I'm completely with you on this one. OpenBSD's lint is overzealous, >> especially when indexing with size_t. It's ridiculous: malloc and >> company /demand/ size_t when allocating memory---yet the same type >> can't be used to iterate over the array? Faugh. >> >> Please leave the code as-is, in this case: I just wanted to be sure >> that they warnings are benign. > > Hm, i think part of these changes actually make the code easier to > understand. I mostly freaked out on those that don't seem to allow > any sane way to please lint, and of course on the indexing issue. > >> I'll probably slowly cast out (har, har) explicit casts used to quiesce >> lint. The same goes with those absurd pre-loop LINTED comments. > > Yes, i think getting rid of most of the LINTED comments is good, > because they don't even tell you what is special about the next line. > I also think that explicit casts when indexing arrays is rather ugly. > > But when you do indeed cast from one type to another, not trivially > compatible type, making the cast explicit does not seem that bad, > it provides a hint that something potentially dangerous is happening > at that place. As long as we have many such casts in our code, > i'm not sure having them implicit and lint complain is better > than having them explicit. Rather, i'm wondering whether there > are techniques to avoid such problems in the first place, in the > design stage or whenever... > > That said, i have thrown out those parts of my term.c diff that > seemed silly to me. I think the rest makes sense in any case. > As it is tested, i could as well put it in, right? > > This is what it does: > * make the initial maxvis/mmax calculation easier to understand > * where real, non-indexing casts happen, make them explicit > * avoid a few lint warnings that can easily be fixed > * remove one needless LINTED comment > > Yours, > Ingo Yes, I like this---much cleaner. Please commit. Thanks! Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv