"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
QUERY
>>>>> "Jerry" == Jerry James <james(a)xemacs.org> writes:
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.
I'll do the work if we make such a decision. Please, everyone, do let
me know if I'm committing some ghastly style crime.
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.
Ah, good point. I had the mindset that the assertions always do
something, but of course that is not true. Hmmmmmm.... so how should we
handle situations like this? An "if (d) { ... }" is just masking the
problem, is it not? Wouldn't it be better to segfault there so we could
find out about the problem?
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.
As in the other case, WINDOW_WIDTH is used all over the place in
window.c already, so I'm not sure this constitutes the breaking of an
abstraction.
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department
http://www.cs.usu.edu/~jerry/
Utah State University