Re: Problem report #61

[Stuart D. Herring]

>     > 1870          if (current_buffer == prev_buffer
>     > 1871              && last_point_position != PT
>     > 1872              && NILP (Vdisable_point_adjustment)
>     > 1873              && NILP (Vglobal_disable_point_adjustment)
>     > 1874              && !already_adjusted)
>     >
>     > Event uninit_use: Using uninitialized value "prev_modiff"
>     > Also see events: [var_decl]
>     >
>     > 1875            adjust_point_for_property (last_point_position, MODIFF 
> !=
>     > prev_modiff);
>     > 1876
>
>     This can only happen if last_point_position at entry to command_loop_1
>     isn't equal to (point) at this point (ha) and read_key_sequence
> returns -1
>     the first time through the loop (before already_adjusted is set).
> Maybe
>     some nasty filter or timer could cause this?  If so, should probably
> start
>     with already_adjusted set to 1 so as to avoid random extra adjusts.
> If
>     not, no bug.
>
> I think this cannot really fail, because if prev_modiff has not been set,
> then prev_buffer hasn't been set either, which means it is NULL,
> which means it does not equal current_buffer.
>
> But it is easy enough to initialize prev_modiff.  I will.

That isn't the whole problem; already_adjusted is also uninitialized if
that code path is taken.  However, prev_buffer is always NULL if the first
call to read_key_sequence returns -1 (which is the only way for either of
these variables to be uninitialized), so there's no bug at all.  I didn't
catch that on the first reading; thanks.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.