2

Per the spec of pset5,

You’re welcome to get started by copying (yet again) copy.c and naming the copy resize.c. But spend some time thinking about what it means to resize a BMP. (You may assume that n times the size of infile will not exceed 2^32 - 1.)

why 2^32 -1?

1

The spec you're quoting does not actually say that "size of a bmp can't exceed 2^32 -1" as you are (mis)interpreting.

It says that, in order to code your implementation of resize.c, you may assume that.

What (I think) that sentence is telling you, is that when you eventually decide on how to implement your buffer and output to disk it'll be enough for you to asume that the size of such output file will never be larger than (approx.):

2^32 - 1 = 4294967295 Bytes / 1024 = 4194304 kBytes / 1024 = 4095 MBytes / 1024 = 4 Gbytes

If such limit was, say, twice as high, you may get in trouble writing it down to the disk. Especially if your filesystem is FAT32 (still common in windows machines), which can handle files up to 4Gb large.

And even in the appliance, you may get in trouble with free space in your virtual HD.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .