Re: [PATCH 21.5] More fun with static checkers

QUERY Thanks for doing all this, Jerry! Despite my queries, I don't object to a commit of the whole bunch; I can see you have some unquestionable fixes in areas where I have experienced problems (no, I can't connect any to crashes or bugs directly yet), so getting them committed is a priority IMO. If we decide it would be better style to ignore the checkers for some of these, I can go back and revert the changes later. Jerry> device-x.c: At the top of the function we assert(d != Jerry> NULL), and none of the intervening code changes the value Jerry> of d. Therefore, we don't need to check d here; this Jerry> comparison is always true. (Indeed, if it were not, then Jerry> the next line, which dereferences d, would be wrong.) Maybe it would be better to move the line that dereferences d into the scope of the if () {...}? The argument would be that when we are not error-checking (so asserts expand to nothing), we may want to handle problems ourselves rather than let X have a chance to crash us. In this particular case, that is probably not true; but I don't think we should let the static checker make our decision for us here. Jerry> window.c: The macro CURSIZE checks the value of widthflag. Jerry> We know the value of widthflag; it is nonzero. Therefore, Jerry> it is okay to expand CURSIZE and pull out the part that is Jerry> evaluated when widthflag is nonzero. As I mentioned elsewhere, it's not obvious to me that breaking into such abstractions is a good idea, but if we do it, I think we should consider eliminating the abstraction. Also, the macro is weird, as it creates a variable lvalue for something that is only used as an rvalue. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.