Why aren't padding bytes in executables optimized?

Question

When I create a small Mac Mach-O executable, "Hello World" written in C for example, it's about 48k in size, because of alignment padding. Yet at the same time I can define 100k of zero-es in the .bss section (for example by specifying a static array of 100k chars) and it's adding just a few bytes to my executable on disk.

I wonder why the padding(, which only plays a role after being loaded, I suppose) is not also "packed" somehow.

Answer 1

You seem not to appreciate the role of padding: to ensure that the size of an object satisfies a constraint, such as being a multiple of a specific number. The values of padding bytes typically are not significant, but their presence is indispensable.

Exactly the opposite is the case for objects assigned to an ELF (say) .bss section: their values are important, but their sizes do not need to be reflected by their on-disk representations. Moreover, the values of such objects are established simply by the fact that they are assigned to .bss, so indeed, each one consumes O(1) space in the binary with respect to the size of its in-memory representation.

Addendum: it is conceivable that a binary format could be designed that carried compressed data, so that such padding indeed was compressed on disk. One can only speculate about why such formats are not popular, but I think it's pretty safe to guess that at least part of the answer is that the simplicity and loading speed of uncompressed binary formats are more valued than the comparatively small amounts of space saving that compressed formats could achieve.