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@xxxxxxxx>
> > 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....