On Sat, Jun 11, 2005 at 05:39:31PM -0400, Daniel Jacobowitz wrote: > On Tue, May 31, 2005 at 09:21:29PM +0930, Ron wrote: > > Package: libncurses5 > > Version: 5.4-4 > > Severity: normal > > > > Hi, > > > > doing something like, for example, mvwprintw( stdscr, 23, 79, "x" ) > > in an 80 x 24 terminal returns ERR even though the entire string can be > > (and is) displayed correctly on the screen. > > > > The ERR would appear to be based on advancing the cursor position to > > an invalid row in preparation for the next addch -- but since we never > > write to that invalid position, it seems a bit unproductive to report > > an error when writing to the last legal position before it. > > > > I can't find anything authoritative that specifies what _should_ happen > > here, but the current behaviour does not seem very useful if an app > > wishes to permit writing to the lower right cell, _and_ check for errors > > that may be reported by libncurses. > > > > I have a vague memory of some historical issue related to this, but > > can't pin it down for the moment. > > Well, if I understand the problem right, the cursor's location _would_ > be off the screen after doing this.
Yes, I think that is correct to say. The associated question being: is that, in and of itself, an error, when it occurs as a side effect of some otherwise legal action (like writing to the LR corner). Obviously it should be an error to move() the cursor there explicitly, as there is no intrinsic value at all to do that, but here we advance it to an illegal position as a(n avoidable) side effect (of allowing writes to the LR corner on full screen windows that don't scroll, and assuming an illegal position is _next_), while the user only commits to creating an error if the cursor is not subsequently moved to a legal position for the next write. That is to say, the error itself is committed by the lib (by not advancing the cursor to a _legal_ position after making a legal write), but it is reported to the user in the same way as a failed user operation would otherwise be. I could probably make a fair argument to call that a bug in the lib from what I can see today. > This is the closest that I can see: > > * The _WRAPPED flag is useful only for telling an application that we've just > * wrapped the cursor. We don't do anything with this flag except set it when > * wrapping, and clear it whenever we move the cursor. If we try to wrap at > * the lower-right corner of a window, we cannot move the cursor (since that > * wouldn't be legal). So we return an error (which is what SVr4 does). > * Unlike SVr4, we can successfully add a character to the lower-right corner > * (Solaris 2.6 does this also, however). This looks like the crux of it from what I can see looking again. And it would seem to confirm that the actual error here is a permanent contradiction in the program logic (feel free to shoot me down at any point here). We allow writing to the LR corner (unlike SVr4 / like Solaris). We advance the cursor automatically when we write. We report moving the cursor off the screen as an error (like SVr4 / ?). The result for ncurses being: it is always an error to write to the LR corner, but if you ignore that error, it will work. I think that is just a different sort of error :-) SVr4 seems to be consistent with its own rules, and I'll presume (but it would be nice if someone can confirm) that Solaris probably is also. We pick the cream from both worlds, but leave programmers in the position of, "it always just works, so don't bother checking for errors" -- which is great when you are in a hurry to whip something up, but not always what you want from every piece of code. Some code needs to know when what it asked for was not done, in this case ERR (success) is indistinguishable from ERR (unexpected failure). > I don't think the defined interfaces for ncurses allow any way for you > to figure this out. The best you could do would be check whether > _WRAPPED was set; that makes it very likely, if not actually certain, > that the lower right cell was filled. Assuming the string wasn't too > long for the screen, of course. Indeed, though this seems rather self defeating to me. It is quite unportable to check for a magic flag in an otherwise opaque structure, to find out if an operation succeeded that we report as an error in order to be 'portable' wrt SVr4 behaviour -- which we don't actually limit ourselves to. Especially so, when (in any analogue to mvprintw at least) it is probably easier to figure it out from x,y + strlen. But it still leaves the problem of what to do if a _real_ error for some other reason occurs while writing to that position. It is now impossible to know that. So... I'm looking at the code below that comment right now, and I think I'd like to change that to do something other than return ERR in this case. Possibly it should advance the cursor to a _legal_ position, if it allows writes to that point. I understand that _any_ change of this nature is likely to be contentious, but I hope the logical faux pas of what we already have is evident enough for it to merit consideration by the relevant maintainers. I'll be happy to make and test a patch if there is agreement on a desirable remedy. Who (else) would I need to convince to make that a useful thing to pursue? cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
