Re: [PATCH] Detect strto* failures based on errno.

Dave Chinner
2014-07-16T23:32:53Z

On Wed, Jul 16, 2014 at 09:44:07AM +0200, Arkadiusz Miśkiewicz wrote:
> On Wednesday 16 of July 2014, Dave Chinner wrote:
> > On Mon, Jul 14, 2014 at 09:56:59AM +0200, Arkadiusz Miśkiewicz wrote:
> > > Code was testing for ERANGE errno only in some places. In other places
> > > it didn't do any errno checking at all.
> > >
> > > Unify strto* result testing by treating any non zero errno as failure.
> > >
> > > Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
> >
> > This patch appears to cause xfs/071 to fail:
> >
> >
> >
> > Writing 512 bytes, offset is +0 (direct=false)
> > -pwrite64: File too large
> > +non-numeric offset argument -- <OFFSET>
> > Reading 512 bytes (direct=false)
> > read 0/512 bytes at offset <OFFSET>
> > ...
> > (Run 'diff -u tests/xfs/071.out
> > /home/dave/src/xfstests-dev/results//xfs/071.out.bad' to see the entire
> > diff)
> >
> > Can you have a look into this?
>
> The test runs:
> xfs_io -c 'pwrite 9223373136366403583 512' file
>
> where 9223373136366403583 is bigger than LLONG_MAX (9223372036854775807), so
>
> # LC_ALL=C xfs_io -c 'pwrite 9223373136366403583 512' ./x
> (MYDEBUG)strerror(34): Numerical result out of range
> non-numeric offset argument -- 9223373136366403583
>
>
> What would be best approach to fix this - some cvtunum for unsigned long long?

I'm pretty sure that cvtnum is only supposed to work with positive
integers - it returns negative values as an error. hence just
changing to use strtoull() would probably fix the issue.

The caller can determine if a negative number is valid or not....

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com