Re: term.c and lint

[Kristaps Dzonsons <kristaps@bsd.lv>]

>> 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