[PATCH] Detect strto* failures based on errno.

[Dave Chinner]

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 at 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 at fromorbit.com