In computer programming, the name .bss or bss is used by many compilers and linkers for a part of the data segment containing statically-allocated variables represented solely by zero-valued bits initially (i.e., when execution begins). It is often referred to as the "bss section" or "bss segment".
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates and initializes memory for the bss section when it loads the program. Operating systems may use a technique called copy on write to efficiently implement the bss segment (McKusick & Karels 1986). In embedded software, the bss segment is mapped into memory that is initialized to zero by the C run-time system before
main() is entered.
On some computer architectures the application binary interface also supports an sbss segment for "small data". Typically, these data items can be accessed using shorter instructions that may only be able to access a certain range of addresses.
Historically, BSS (from Block Started by Symbol) was a pseudo-operation in UA-SAP (United Aircraft Symbolic Assembly Program), the assembler developed in the mid-1950s for the IBM 704 by Roy Nutt, Walter Ramshaw, and others at United Aircraft Corporation. The BSS keyword was later incorporated into FAP (FORTRAN Assembly Program), IBM's standard assembler for its 709 and 7090/94 computers. It defined a label (i.e. symbol) and reserved a block of uninitialized space for a given number of words (Timar 1996). In this situation BSS served as a shorthand in place of individually reserving a number of separate smaller data locations. Some assemblers support a complementary or alternative directive BES, for Block Ended by Symbol, where the specified symbol corresponds to the end of the reserved block.
BSS in C
In C, statically-allocated objects without an explicit initializer are initialized to zero (for arithmetic types) or a null pointer (for pointer types). Implementations of C typically represent zero values and null pointer values using a bit pattern consisting solely of zero-valued bits (though this is not required by the C standard). Hence, the BSS segment typically includes all uninitialized objects (both variables and constants) declared at file scope (i.e., outside any function) as well as uninitialized static local variables (local variables declared with the
static keyword); static local constants must be initialized at declaration, however, as they do not have a separate declaration, and thus are typically not in the BSS section, though they may be implicitly or explicitly initialized to zero. An implementation may also assign statically-allocated variables and constants initialized with a value consisting solely of zero-valued bits to the BSS section.
Peter van der Linden, a C programmer and author, says, "Some people like to remember it as 'Better Save Space.' Since the BSS segment only holds variables that don't have any value yet, it doesn't actually need to store the image of these variables. The size that BSS will require at runtime is recorded in the object file, but BSS (unlike the data segment) doesn't take up any actual space in the object file."
BSS in Fortran
In Fortran, common block variables are allocated in this segment . Note that even on x86_64, 32-bit pointers are often used to address this data, limiting the size of the common blocks to 2 GB. 
- Network Dictionary. Javvin Press, 2007, p. 70.
- Coding for the MIT-IBM 704 Computer October 1957, p. V-10
- Free Software Foundation, Inc. "38.9. Directives". Using as: Using as, the Gnu Assembler. Retrieved Feb 22, 2014.
- Peter van der Linden, Expert C Programming: Deep C Secrets, Prentice Hall 1994, p. 141
- How does Fortran 77 allocate common-block variables?, 
- gfortran for dummies: What does mcmodel=medium do exactly?, 
- Stevens, W. Richard (1992). Advanced Programming in the Unix Environment. Addison–Wesley. Section 7.6. ISBN 0-201-56317-7.
- Timar, Ted; et al. (1996). "Unix - Frequently Asked Questions (1/7)". Question 1.3.
- McKusick, Marshall Kirk; Karels, Michael J. (1986). "A New Virtual Memory Implementation for Berkeley UNIX" (PDF). University of California, Berkeley. p. 3. CiteSeerX .