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
