fstests: Don't use gawk's strtonum breaking existing fstests

fstests: Don't use gawk's strtonum breaking existing fstests

[Nikolay Borisov]

Hello,

Following upstream commit:
https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?id=37520a314bd472ed720ed0611c6b69e418be9b61

breaks btrfs/095 and btrfs/098 tests.

Re: fstests: Don't use gawk's strtonum breaking existing fstests

[Nikolay Borisov]

On 11.12.19 г. 17:53 ч., Nikolay Borisov wrote:
> Hello,
> 
> Following upstream commit:
> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?id=37520a314bd472ed720ed0611c6b69e418be9b61
> 
> breaks btrfs/095 and btrfs/098 tests.
> 

The problem is that the old code was using gawk's strtonum and returning
a base 10 number from an octal input. Whereas the existing code gets an
octal number which is again parsed as an octal when using printf. So the
path in question needs to either by reverted or extended so that the
necessary conversion from octal to base 10 is performed _before_ calling
printf.

Re: fstests: Don't use gawk's strtonum breaking existing fstests

[Qu Wenruo]

On 2019/12/12 上午12:33, Nikolay Borisov wrote:
>
>
> On 11.12.19 г. 17:53 ч., Nikolay Borisov wrote:
>> Hello,
>>
>> Following upstream commit:
>> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?id=37520a314bd472ed720ed0611c6b69e418be9b61
>>
>> breaks btrfs/095 and btrfs/098 tests.
>>
>
> The problem is that the old code was using gawk's strtonum and returning
> a base 10 number from an octal input. Whereas the existing code gets an
> octal number which is again parsed as an octal when using printf. So the
> path in question needs to either by reverted or extended so that the
> necessary conversion from octal to base 10 is performed _before_ calling
> printf.
>

Well, octal values really makes no sense. We should go either hex, or
human readable decimal.

Octal should only be left for certain historical use cases, like user
privileges. For content dump, octal is never a good use case to show offset.

Since current filter_od can't handle -Ax yet, what about just use hash
instead of the problem prone od?
And put the od output into seqres.full for later debug?

Thanks,
Qu

Re: fstests: Don't use gawk's strtonum breaking existing fstests

[Nikolay Borisov]

On 12.12.19 г. 7:16 ч., Qu Wenruo wrote:
> 
> 
> On 2019/12/12 上午12:33, Nikolay Borisov wrote:
>>
>>
>> On 11.12.19 г. 17:53 ч., Nikolay Borisov wrote:
>>> Hello,
>>>
>>> Following upstream commit:
>>> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?id=37520a314bd472ed720ed0611c6b69e418be9b61
>>>
>>> breaks btrfs/095 and btrfs/098 tests.
>>>
>>
>> The problem is that the old code was using gawk's strtonum and returning
>> a base 10 number from an octal input. Whereas the existing code gets an
>> octal number which is again parsed as an octal when using printf. So the
>> path in question needs to either by reverted or extended so that the
>> necessary conversion from octal to base 10 is performed _before_ calling
>> printf.
>>
> 
> Well, octal values really makes no sense. We should go either hex, or
> human readable decimal.
> 
> Octal should only be left for certain historical use cases, like user
> privileges. For content dump, octal is never a good use case to show offset.
> 
> Since current filter_od can't handle -Ax yet, what about just use hash
> instead of the problem prone od?
> And put the od output into seqres.full for later debug?

I disagree, using the output of od one can see the actual content of
extents and can quickly diagnose the failure.


> 
> Thanks,
> Qu
>