Re: lib/41257: curses: getyx + wmove violates least astonishment past end-of-line

[Brett Lymn <blymn%baesystems.com.au@localhost>]

On Tue, Apr 21, 2009 at 06:10:01AM +0000, jld%panix.com@localhost wrote:
> 
> This may not be the Right Thing, but in simple testing it does appear
> to work, and fix the original application that was having trouble.
> Alternately, wmove() could be modified to accept one-past-the-end
> coordinates as input and set up the state appropriately, but I'm not
> familiar enough with the curses internals to know if that would have
> unintended consequences.

No, it is not the correct thing to do - the x & y coordinates should
always be correct after adding bytes trying to paper over the cracks
by diddling the reporting routines will result in pain, lossage and
confusion because the internal cursor state is still wrong.

All the *add* functions end up calling a couple of routines in
addbytes.c, _cursesi_addwchar() and _cursesi_addbyte().  I suspect the
problem arises where the current x position is compared for equality
with (maxx - 1), in the narrow character case this would probably work
but in the wide character case we may skip ahead a few characters when
inserting a wide character so the equality check would fail, this
probably needs to be >= instead of ==

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."