text,data and bss

[c.lang.myself]

i just got to know there are three different sections in which we can
divide our program
*Text section
*Data section
*Bss

i think text section contain our code,data section include heap,stack
(?) etc.

Can any body throw light on Bss section...

[Richard Tobin]

In article <9c************ *************** @TEKSAVVY.COM-Free>,
Lew Pitcher <le*********@di gitalfreehold.c awrote:

>The entire purposes of .bss was to get zero-initialized variables out of
.data. In a sense, it's a compression scheme.

>IIRC, the entire purpose of .bss was to get /uninitialized/ variables out
of .data. To quote "A tour through the Unix C compiler" (D. M. Ritchie,
Bell Laboratories, circa 1979)
"BSS means that subsequent information is to be compiled as uninitialized
static data"

But "unitialise d" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

Here is a more detailed quote from Ritchie, in the UNIX Assembler
Reference Manual (which I found a copy of at
http://www.tom-yam.or.jp/2238/ref/as.pdf):

The bss segment may not contain any explicitly initialized code or
data. The length of the bss segment (like that of text or data) is
determined by the high-water mark of the location counter within
it. 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. Typically the bss segment is set up by
statements exemplified by

lab:.=.+10

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.

I think it's clear that references to the bss containing unitialised
variables are meant to imply un-(initialised to non-zero).

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 16 Nov 2008 18:47:55 +0000, Richard Tobin wrote:

But "unitialise d" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

What about the bytes of a union that are not part of the initialised sub-
object?

[Richard Tobin]

In article <gf**********@n ews.motzarella. org>,
Harald van Dijk <tr*****@gmail. comwrote:

>But "unitialise d" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

>What about the bytes of a union that are not part of the initialised sub-
object?

I suppose so. But you could hardly put them in a different section
from the initialised bytes of the union, so there's still no use for
a really-uninitialised section.

-- Richard

--
Please remember to mention me / in tapes you leave behind.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 16 Nov 2008 19:02:54 +0000, Richard Tobin wrote:

In article <gf**********@n ews.motzarella. org>, Harald van Dijk
<tr*****@gmail. comwrote:

>>But "unitialise d" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

>>What about the bytes of a union that are not part of the initialised
sub- object?

I suppose so. But you could hardly put them in a different section from
the initialised bytes of the union, so there's still no use for a
really-uninitialised section.

On systems where pointer types or floating-point types are not initialised
to all-bits zero (which are admittedly uncommon, but real), and the
initialised member of the union is of pointer or floating-point type, it
doesn't make sense to put the union in a zero-initialised section.

[Richard Tobin]

In article <gf**********@n ews.motzarella. org>,
Harald van Dijk <tr*****@gmail. comwrote:

>>>But "unitialise d" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

>>>What about the bytes of a union that are not part of the initialised
sub- object?

>I suppose so. But you could hardly put them in a different section from
the initialised bytes of the union, so there's still no use for a
really-uninitialised section.

>On systems where pointer types or floating-point types are not initialised
to all-bits zero (which are admittedly uncommon, but real), and the
initialised member of the union is of pointer or floating-point type, it
doesn't make sense to put the union in a zero-initialised section.

Quite so. Is there some reason you think I'm disputing that?

If 0.0 is all zeros, then a zero-initialised section can be used
for it. If it's not, then you need something like .data that can
be initialised to any value. Neither case suggests a .bss that is
not initialised at all.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:

In article <gf**********@n ews.motzarella. org>, Harald van Dijk
<tr*****@gmail. comwrote:

>>>>But "unitialise d" static variables are implicitly initialised to
zero. There are no really-uninitialised static variables in C.

>>>>What about the bytes of a union that are not part of the initialised
sub- object?

>>I suppose so. But you could hardly put them in a different section
from the initialised bytes of the union, so there's still no use for a
really-uninitialised section.

>>On systems where pointer types or floating-point types are not
initialised to all-bits zero (which are admittedly uncommon, but real),
and the initialised member of the union is of pointer or floating-point
type, it doesn't make sense to put the union in a zero-initialised
section.

Quite so. Is there some reason you think I'm disputing that?

If 0.0 is all zeros, then a zero-initialised section can be used for it.
If it's not, then you need something like .data that can be initialised
to any value. Neither case suggests a .bss that is not initialised at
all.

Oh, sure, initialised to whatever random bytes the compiler happened to
have in memory when laying out the .data section or equivalent is
effectively uninitialised to me.

But depending on the number of bytes, it may be a waste of space to store
them all when there's no need to do so. To use an extreme example:

union {
double d;
char a[1000000];
} u;

Is there a benefit in filling a[sizeof(double)] through a[999999] in the
generated object or at startup? The drawback seems obvious to me.
Especially if u.d needs to be filled in the startup code anyway (let's say
because the system doesn't have a .data section or equivalent), I can
imagine the rest of a being semi-random.

[Stephen Sprunk]

Harald van Dijk wrote:

On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:

>In article <gf**********@n ews.motzarella. org>, Harald van Dijk
<tr*****@gmail .comwrote:

>>On systems where pointer types or floating-point types are not
initialised to all-bits zero (which are admittedly uncommon, but real),
and the initialised member of the union is of pointer or floating-point
type, it doesn't make sense to put the union in a zero-initialised
section.

Quite so. Is there some reason you think I'm disputing that?

If 0.0 is all zeros, then a zero-initialised section can be used for it.
If it's not, then you need something like .data that can be initialised
to any value. Neither case suggests a .bss that is not initialised at
all.

Oh, sure, initialised to whatever random bytes the compiler happened to
have in memory when laying out the .data section or equivalent is
effectively uninitialised to me.

Uh, what? If all-bits-zero (which is what you'd get in .bss) does not
mean 0.0, then the compiler would instead create an entry in .data that
_does_ mean 0.0. There is no initialization to "whatever random bytes
the compiler happened to have in memory"; either way, the variable will
end up being 0.0.

If the OS does not zero-fill the .bss section on creation, then the
compiler must insert code to correct that before execution began,
eliminating any random bytes that might happened to be in memory. If it
didn't, the C implementation would be non-conforming. However, the need
to do this should be rare since giving a program leftover data from
another program can be a serious security hole.

S

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 17 Nov 2008 00:25:58 -0600, Stephen Sprunk wrote:

Harald van Dijk wrote:

>On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:

>>In article <gf**********@n ews.motzarella. org>, Harald van Dijk
<tr*****@gmai l.comwrote:
On systems where pointer types or floating-point types are not
initialise d to all-bits zero (which are admittedly uncommon, but
real), and the initialised member of the union is of pointer or
floating-point type, it doesn't make sense to put the union in a
zero-initialised section.

Quite so. Is there some reason you think I'm disputing that?

If 0.0 is all zeros, then a zero-initialised section can be used for
it.
If it's not, then you need something like .data that can be
initialised
to any value. Neither case suggests a .bss that is not initialised at
all.

Oh, sure, initialised to whatever random bytes the compiler happened to
have in memory when laying out the .data section or equivalent is
effectively uninitialised to me.

Uh, what? If all-bits-zero (which is what you'd get in .bss) does not
mean 0.0, then the compiler would instead create an entry in .data that
_does_ mean 0.0. There is no initialization to "whatever random bytes
the compiler happened to have in memory"; either way, the variable will
end up being 0.0.

Given

union {
double d;
char x[1000];
} u = { 0 };

u.d will be initialised to zero, but I was talking about the bytes that
follow u.d.

[Stephen Sprunk]

Harald van Dijk wrote:

On Mon, 17 Nov 2008 00:25:58 -0600, Stephen Sprunk wrote:

>Harald van Dijk wrote:

>>On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:
If 0.0 is all zeros, then a zero-initialised section can be used for
it.
If it's not, then you need something like .data that can be
initialised
to any value. Neither case suggests a .bss that is not initialised at
all.

Oh, sure, initialised to whatever random bytes the compiler happened to
have in memory when laying out the .data section or equivalent is
effectively uninitialised to me.

Uh, what? If all-bits-zero (which is what you'd get in .bss) does not
mean 0.0, then the compiler would instead create an entry in .data that
_does_ mean 0.0. There is no initialization to "whatever random bytes
the compiler happened to have in memory"; either way, the variable will
end up being 0.0.

Given

union {
double d;
char x[1000];
} u = { 0 };

u.d will be initialised to zero, but I was talking about the bytes that
follow u.d.

In that example, isn't the part of u.x not overlapping with u.d supposed
to be zero-filled as well?

This example could be inefficient if all-bits-zero wasn't 0.0, forcing
the entire union into .data instead of .bss, but I don't think you'd get
"random bytes" in the non-overlapping part of u.x.

S

[jameskuyper]

Stephen Sprunk wrote:

Harald van D©¦k wrote:

....

Given

union {
double d;
char x[1000];
} u = { 0 };

u.d will be initialised to zero, but I was talking about the bytes that
follow u.d.

In that example, isn't the part of u.x not overlapping with u.d supposed
to be zero-filled as well?

No.