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.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
