Re: Z and Y suffixes in xstrtol.c

[Pádraig Brady]

On 15/12/14 07:45, isabella parakiss wrote:
> There's a problem with xstrtol.c: it cannot support Z and Y suffixes because
> 1024**7=1180591620717411303424 and 1024**8=1208925819614629174706176 but
> STRTOL_T_MAXIMUM is (at most) UINT64_MAX=18446744073709551615.
> 
> I know this is not much of an issue since Z and Y are so rarely used, but it
> causes incongruences with programs such as GNU dd.  Its man page says:
> 
>> N and BYTES may be followed by the following multiplicative suffixes: c =1,
>> w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M
>> GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.
> 
> But in fact dd doesn't support them:
> 
> $ dd if=/dev/null count=1P
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.000698762 s, 0.0 kB/s
> $ dd if=/dev/null count=1E
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.000698762 s, 0.0 kB/s
> $ dd if=/dev/null count=1Z
> dd: invalid number ‘1Z’
> $ dd if=/dev/null count=1Y
> dd: invalid number ‘1Y’

truncate gives a little more info by using the errno:

  $ truncate -s1Z /dev/null
  truncate: invalid number ‘1Z’: Value too large for defined data type

I wonder should other coreutils use that for "invalid number..." errors?

Anyway there is nothing wrong with xstrtol() here as it's correctly
detecting the overflow.  As for dd documenting the possibility,
that's OK too since theoretically 128 bit ints could be used.
However this is of no practical concern as the quantities that
dd operates on would have to be based on the base types supported
by the platform.  If larger quantities were applicable then we
could use long double internally to dd and operate on that.

thanks,
Pádraig