Re: Zooming issues in interactive terminals

[Ethan A M. <merritt@u.washington.edu>]

On Friday 16 May 2008 16:07, Ethan Merritt wrote:
> On Friday 16 May 2008 15:47, Lutz Maibaum wrote:
> > 
> > According to the manpage of my standard C library (glibc 2.6.1 release 18.3 
> > for X86-64, openSUSE), atol does not check for overflow errors, whereas 
> > strtol does. It also has the following to say:
> > 
> >     You should not check for errors by examining the return value of
> >      `strtol', because the string might be a valid representation of
> >      `0l', `LONG_MAX', or `LONG_MIN'.  Instead, check whether TAILPTR
> >      points to what you expect after the number (e.g. `'\0'' if the
> >      string should end after the number).  You also need to clear ERRNO
> >      before the call and check it afterward, in case there was overflow.
> 
> Yeah. To do it properly we should use strtol() instead.
> 
> In 4.2 we switched to using strtod() and strtol() for data input.
> It would make sense to do the same when reading from the command line.

I've made this change in scanner.c get_num().
It fixes the overflows on a system that handles stderr properly (linux)
and does no worse that the previous code on a system that doesn't (sunos 4.1).

This change has the happy side effect of allowing hex constants on the
command line, which makes it a whole lot easier to specify RGB colors
in-line:
   plot 'foo' using 1:2:($3>$4 ? 0xff0000 : 0x0000ff) lc rgb variable

-- 
Ethan A Merritt