Re: Zooming issues in interactive terminals

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

On Friday 16 May 2008 15:47, Lutz Maibaum wrote:
> On Friday 16 May 2008 15:23:35 Ethan Merritt wrote:
> > On Friday 16 May 2008 15:07, Lutz Maibaum wrote:
> > > thanks for looking into this. I must admit I don't quite understand
> > > your proposed changes to the scanner, but as a quick fix would it be
> > > sufficient to replace the %g in the line above by %E, which always
> > > includes a decimal point?
> >
> > That would probably fix it for the specific case of zooming,
> > but the general case would still be broken.  As it stands, all integer
> > constants in the input stream are silently truncated to LONG_MAX on
> > a "normal" machine configuration.  Yours at least prints an error
> > message.
> 
> 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.

-- 
Ethan A Merritt