On 4/2/13, Daniel Shahaf <danielsh_at_elego.de> wrote:
> I'm not sure how to interpret a return value of (0,0) that's not
> accompanied by an error flag (C errno!=0, or a Python exception). Is
> that normal behaviour, a bug we should be working around in our code, or
> an indication of a bug in our logic in the preceding lines?
>
I took a look around a few distros[1], and in no case does this function
return an error, to cater for dumb terminals if I understand this correctly.
More info: http://en.wikipedia.org/wiki/POSIX_terminal_interface
> i.e., if (0,0) means "_get_term_width() was going 35mph in a school zone
> at the time of the call to fcntl.ioctl()", we should fix that.
_get_term_width()'s 'sin' is not checking for a sane minimum size, which
is I think is a reasonable omission, because setting up a TERM with a
claimed size of (0,0) isn't easily anticipated and we're only crashing
svn and not aeroplanes :>
> But if (0,0) is just a terminal emulator bug, or expected behaviour, then +1 to
> commit.
I think since emacs is mainly affected here, it's definitely worthwhile
to fix that because the output is hard to read, and whilst the 'success'
message is in green, someone who is red-green color blind won't be
able to read it easily without at least one space.
Also, the bug eats the progress meter, which is a pity.
> This change will actually change the output if you resize the terminal
> window while running tests interactively (at least in terminal emulators
> that support the ioctl_GWINSZ approach).
Oops, I hadn't thought that someone might adjust their window mid-test.
However, resizing your window results in quite a visual mess in either
case. -- best avoided :)
> I'm not objected to it, but it's not clear to me what it gains either (shaves 100 syscalls
> from a 'make check' run?).
I agree, it's a a bit very picky to fix this, now that I think about it
-- coding on muds gets you this reflexive habit lest you summon the lag
monster. LPC MUDS are single threaded and Objective C is interpreted,
and every object has a computational limit per heartbeat and the driver
removes objects that time out before completing from the execution list
as irretrievably broken.
So, if you're doing anything 'fancy', you often end up staggering
executions over a number of game turns, and every even so small
inefficiency counts because it all adds up and the entire game is affected.
Gabriela
--------------------------------------------
[1]
The linux kernel (linux-3.8.5) end of the syscall:
case TIOCSWINSZ:
return tiocswinsz(real_tty, p);
static int tiocgwinsz(struct tty_struct *tty, struct winsize __user *arg)
{
int err;
mutex_lock(&tty->termios_mutex);
err = copy_to_user(arg, &tty->winsize, sizeof(*arg));
mutex_unlock(&tty->termios_mutex);
return err ? -EFAULT: 0;
}
The freebsd 9.1 kernel code:
case TIOCGWINSZ:
/* Obtain window size. */
*(struct winsize*)data = tp->t_winsize;
return (0);
4.4BSD-Lite2:
int
ttioctl(tp, cmd, data, flag)
register struct tty *tp;
u_long cmd;
void *data;
int flag;
{
/* <snip> */
case TIOCGWINSZ: /* get window size */
*(struct winsize *)data = tp->t_winsize;
break;
/* <snip> */
return (0);
}
Received on 2013-04-06 14:02:26 CEST