Why did ancient Unix perform BSS segment initialization?

Question

I just came across this good question at SO: Why are global and static variables initialized to their default values? But I don't like any of the answers and I actually think it remains unanswered: why does C and C++ perform zero initialization of static storage duration variables?

C++ surely does it because C does it. And C likely does it simply because that's how ancient 1970s Unix did it, as specified by ABI or executable formats? The Wikipedia about .bss suggests that the origin of the name goes even further back to pre-Unix mainframe computers, but not necessarily as a zero-initialized section until Unix, or...?

At the same time, C does not perform zero initialization of stack or heap memory (automatic or allocated storage). The reason why is supposedly performance, which is also one reason why malloc has not been declared obsolete in favor of calloc.

But can't the same be said about zero initialization of .bss? Doesn't this lead to slower executable boot-up and if we skipped it we would get faster programs? Yet it has been there from the start.

As someone who usually works with embedded systems microcontrollers, I know that it is very common that the CRT comes with an option "fast boot-up" or "non-standard boot-up" skipping .bss and .data initialization in explicit violation of the C standard, just in order to start up faster. Hosted/PC systems don't really have that option but always perform .bss initialization - supposedly inexpensive but it is still overhead.

Does anyone know why .bss zero initialization was introduced and made mandatory when Unix and C were created?

Answer 1

The UNIX PROGRAMMER’S MANUAL (Seventh Edition, Volume 2B) says in the chapter Assembler Reference Manual on page 2 (my emphasis):

The data segment is available for placing data or instructions which will be modified during execution. Anything which may go in the text segment may be put into the data segment. In programs with write-protected, sharable text segments, data segment contains the initialized but variable parts of a program. [...]

The bss segment may not contain any explicitly initialized code or data. [...] The bss segment is actually an extension of the data segment and begins immediately after it. At the start of execution of a program, the bss segment is set to 0. [...] The advantage in using the bss segment for storage that starts off empty is that the initialization information need not be stored in the output file.

So there you have the reason: The data and bss segment are two sides of the same coin (holding initialized data in read-write storage), with the initialization values of the data segment stored in the executable file, while the initialization values of the bss segment are zero, and therefore don't need to be stored.

Answer 2

Is the real question here why C doesn't have syntax for arrays in static storage that are allowed to be truly uninitialized, with random garbage from the previous use being allowed?

Probably because early Unix didn't have a way to get such memory from the kernel: BSS space was always zero-initialized (see dirkt's answer quoting an early Unix man page). This is useful, and avoids duplicating zeroing code into each executable for static storage you do want zero-initialized, e.g. to hold static int staticvar = 0; in a hypothetical C where static int staticvar; could have a non-zero value.

Zeroing fresh pages from the kernel (including the BSS) is also necessary for security on a multi-user system: if a fresh process's BSS had whatever was previously left in that RAM, you'd be leaking kernel data or potentially data from another user's process. (Or pagecache pages from files you don't have permission to read.)

The only real use-case I can see for a hypothetical language feature like char iobuffer[8192] __attribute__((uninitialized)); would be a single-user or embedded system that didn't attempt to do any security, allowing faster process startup by having two parts to the BSS: zeroed and non-zeroed. That's extra complexity beyond just a zeroed BSS for all the zero-init static storage.

Such storage would only be safely usable in programs where the first access was a write, since trap representations exist for integers. For an input buffer, you'd have to code carefully to avoid reading bytes left unwritten by a partial read. But C is happy to provide you with lots of ways to write unsafe code so that's not a clear reason.

But a feature like that would require extra syntax so that's a strong reason not to do it in a small "simple" language like early C. Unless they omitted any guarantee about the initial value of default-initialized static storage, like static int var; not being equivalent to static int var = 0;.

(John Doty commented: K&R first revision (1978) states: "In the absence of explicit initialization, external and static variables are guaranteed to be initialized to zero". So C has required zero-init of static storage since forever, so in terms of C the only question is why. In terms of implementation details, it's a question of whether the OS or user-space does the zeroing. On DOS, I think you did get old values in memory so your startup code would have to zero a BSS if you want that.)

---

Semi-related: Linux 2.6.33 added support for mmap(MAP_UNINITIALIZED), available only if built with CONFIG_MMAP_ALLOW_UNINITIALIZED, for dynamic allocation in that use-case.

The ELF file format implements a BSS by having the virtual size of a segment be larger than the disk/file size of the segment; the file-backed part holds the .data section and other read/write non-zero init things, the no-backing part is the BSS. AFAIK, other systems are similar, and would need a separate type of segment to request non-zeroed anonymous private pages.

Answer 3

The point of bss section was to save space.

If you don't use it then you have to explicitly initialize variables with a zero value and the binaries take more space on disk and it takes more time to load a larger binary.

Also in order to not explicitly to have the need to initiailize variables to zero, you could gather all uninitialized variables into single section and just have small code to initialize it to zero, instead of loading the zeroes from disk to memory.

And uninitialized variables are bad, and you may expect them to be zero, or if you can't expect that, then you need to initialize them yourself to the value you expect to be sure what the value is before using them.

So who clears the bss section is im9lementation dependent. If OS is aware of executable sections it could do it. In some cased it is not the job of the OS to clear bss, but the job of the program itself at startup before calling the main() function. The point still is, data known to be uninitialized is not stored into the binary file, but space for it is reserved and the memory area of these variables is set to zero by OS or program itself.

Answer 4

Since we're talking about early Unix, the fount of minimalism in implementation, I will offer my opinion in a minimal answer:

Zeroing bss memory is low-cost and more useful than not zeroing bss memory, so the decision is easy.

Remember, we're talking about a system where pressing the return key took ~100 mS to get to the computer; another half a millisecond to zero a 256 word bss is not going to be seen as huge overhead, especially in view of what you saved by not reading it off the disk.

Think small.