bug#16409: Some amusing results with dd

[bugs]

So. I'd encountered:
    dd if=/dev/zero of=ubuntunew.img bs=1M count=0 seek=4096

In a man page on creating disc images.
Which seemed rather clever.  dd and lseek create a file of the appropriate size, 
that takes up no space at all until you actually write to it,  say,  shred -n 1 -z ubuntunew.img

So. I thought it'd be a neat way to test the limits of dd.

The dd 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.

What does testing say?
    dd if=/dev/zero of=ubuntunew.img bs=1Y count=0 seek=1
    dd: invalid number ‘1Y’
    dd if=/dev/zero of=ubuntunew.img bs=1Z count=0 seek=1
    dd: invalid number ‘1Z’

dd has no idea what these suffixes are, apparently, regardless of what the man 
page says.

    dd if=/dev/zero of=ubuntunew.img bs=1E count=0 seek=1
    dd: failed to truncate to 1152921504606846976 bytes in output file 
‘ubuntunew.img’: File too large
    dd if=/dev/zero of=ubuntunew.img bs=1P count=0 seek=1
    dd: failed to truncate to 1125899906842624 bytes in output file 
‘ubuntunew.img’: File too large

dd apparently cannot actually create files with sizes that can't be fit in a 64 
bit number?
I'm not sure if that's a dd limitation or this 3.11 kernel and ext4 filesystem.

    dd if=/dev/zero of=ubuntunew.img bs=1T count=0 seek=1
    dd: memory exhausted by input buffer of size 1099511627776 bytes (1.0 TiB)

This one is at first glance perfectly understandable. The buffer size is an abusrd 1 terabyte. 
On the other hand, given the convenience of this count=0 use case for creating a quick "large" image with no actual disc space, 
there's no reason that dd should be attempting to allocate *any* memory. 
Just skip malloc if count is 0.   Allow people to use bs as a convenience for counting in that case.

    dd if=/dev/zero of=ubuntunew.img bs=1G count=0 seek=$((1024*16))
    dd: failed to truncate to 17592186044416 bytes in output file 
‘ubuntunew.img’: File too large

Apparently 16 terabyte files, also too big...


    dd if=/dev/zero of=ubuntunew.img bs=1G count=0 seek=$((1024*15))
    0+0 records in
    0+0 records out
    0 bytes (0 B) copied, 0.000125941 s, 0.0 kB/s

15 terabytes is just fine though.

Well, I thought this was interesting, anyway. Is any of this an actual problem 
in terms of future proofing?

Apologies for any disturbance.