text,data and bss

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

Re: [OT] text,data and bss

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

In article <gfprf1$kof$1@n ews.motzarella. org>, Harald van Dijk
<truedfx@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]

Re: [OT] text,data and bss

Harald van Dijk wrote:

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

>In article <gfprf1$kof$1@n ews.motzarella. org>, Harald van Dijk
><truedfx@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==?=]

Re: [OT] text,data and bss

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 <gfprf1$kof$1@n ews.motzarella. org>, Harald van Dijk
>><truedfx@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]

Re: [OT] text,data and bss

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]

Re: [OT] text,data and bss

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.

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

Re: [OT] text,data and bss

On Mon, 17 Nov 2008 15:27:52 -0600, Stephen Sprunk wrote:

Harald van Dijk 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, it's not, and in the general case, it can't be:

union {
char x[sizeof(double) - 1];
double d;
} u = { 0 };

There isn't any way to zero-initialise the final byte of d. (I'm assuming
sizeof(double) is not 1.)

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.

If real-world compilers don't clear out bits in floating point constants
that don't contribute to the value (admittedly, this is not by a
conforming compiler, but it's not one of the areas in which it doesn't
conform), it wouldn't surprise me if real-world compilers don't clear out
bytes in unions that don't contribute to the value.

[James Harris]

Re: text,data and bss

On 17 Nov, 21:27, Stephen Sprunk <step...@sprunk .orgwrote:

Harald van D©¦k wrote:

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

Harald van D©¦k 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.

I don't think it is possible for C to initialise both components of
the above union to zero - at least not in the general case. Where the
machine has a double zero representation that is not all zero bits it
is impossible to zero both.

James

[James Kuyper]

Re: [OT] text,data and bss

jameskuyper wrote:

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.

Sorry - that wasn't meant to be so abrupt - I accidentally sent that
message when I'd just barely started writing it.

6.2.6.1p6: "When a value is stored in an object of structure or union
type, including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values."

6.2.6.1p7: "When a value is stored in a member of an object of union
type, the bytes of the object representation that do not correspond to
that member but do correspond to other members take unspecified values."

You're probably thinking of the following rule:

6.7.8p21: "... the remainder of the aggregate shall be initialized
implicitly the same as objects that have static storage duration."

However, unions are NOT aggregates, so this rule only applies to
structures or arrays.

[lawrence.jones@siemens.com]

Re: [OT] text,data and bss

Stephen Sprunk <stephen@sprunk .orgwrote:

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?

Not so far, but there's a fair chance that C1X will require it.
--
Larry Jones

Kicking dust is the only part of this game we really like. -- Calvin

[Keith Thompson]

Re: [OT] text,data and bss

lawrence.jones@ siemens.com writes:

Stephen Sprunk <stephen@sprunk .orgwrote:

>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?

>
Not so far, but there's a fair chance that C1X will require it.

Really? How will something like this be handled?

union {
int i;
double d;
};

Suppose sizeof(double) sizeof(int), and double(0.0) isn't
represented as all-bits-zero.

Or consider:

union {
int i;
float f;
void *p;
}

Which member gets zeroed? Will this apply only to non-overlapping
members? (Obviously all top-level members overlap; this can apply
only to submembers.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Stephen Sprunk]

Re: [OT] text,data and bss

Keith Thompson wrote:

lawrence.jones@ siemens.com writes:

>Stephen Sprunk <stephen@sprunk .orgwrote:

>>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?

>>
>Not so far, but there's a fair chance that C1X will require it.

>
Really? How will something like this be handled?
>
union {
int i;
double d;
};
>
Suppose sizeof(double) sizeof(int), and double(0.0) isn't
represented as all-bits-zero.

If you are initializing d, nothing would change since there is no
non-overlapping part of i.

In the case where sizeof(int) sizeof(double), then the non-overlapping
bytes in i would be zero-filled. That is, in fact, what happens with
every implementation I've used (since they zero-fill all memory before
giving it to a process), which is part of why I had thought it was
required. (The is that I rarely use unions, so I keep thinking of the
rules for structs, which are similar but not identical.)

Or consider:
>
union {
int i;
float f;
void *p;
}
>
Which member gets zeroed? Will this apply only to non-overlapping
members? (Obviously all top-level members overlap; this can apply
only to submembers.)

See above. The proposed change would only affect the non-overlapping
parts of members that weren't explicitly initialized.

S

[Keith Thompson]

Re: [OT] text,data and bss

Stephen Sprunk <stephen@sprunk .orgwrites:

Keith Thompson wrote:

>lawrence.jones@ siemens.com writes:

>>Stephen Sprunk <stephen@sprunk .orgwrote:
>>>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?
>>>
>>Not so far, but there's a fair chance that C1X will require it.

>Really? How will something like this be handled?
> union {
> int i;
> double d;
> };
>Suppose sizeof(double) sizeof(int), and double(0.0) isn't
>represented as all-bits-zero.

>
If you are initializing d, nothing would change since there is no
non-overlapping part of i.
>
In the case where sizeof(int) sizeof(double), then the
non-overlapping bytes in i would be zero-filled. That is, in fact,
what happens with every implementation I've used (since they zero-fill
all memory before giving it to a process), which is part of why I had
thought it was required. (The is that I rarely use unions, so I keep
thinking of the rules for structs, which are similar but not
identical.)
>

>Or consider:
> union {
> int i;
> float f;
> void *p;
> }
>Which member gets zeroed? Will this apply only to non-overlapping
>members? (Obviously all top-level members overlap; this can apply
>only to submembers.)

>
See above. The proposed change would only affect the non-overlapping
parts of members that weren't explicitly initialized.

Given:

static union {
int i;
void *p[100];
} obj;

C99 currently states that i is initialized to 0, and the initial value
of p isn't specified. So with the proposed change, all bytes of obj.p
beyond the first sizeof(int) bytes will be set to 0, even if
all-bits-zero isn't a representation of a null pointer?

How is that useful?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones@siemens.com]

Re: [OT] text,data and bss

Keith Thompson <kst-u@mib.orgwrote:

lawrence.jones@ siemens.com writes:

Not so far, but there's a fair chance that C1X will require it.

>
Really? How will something like this be handled?
>
union {
int i;
double d;
};
>
Suppose sizeof(double) sizeof(int), and double(0.0) isn't
represented as all-bits-zero.

The proposal is that the "extra" bytes be initialized to zero (actually,
it says that *all* the bytes are set to zero before the regular
initialization process occurs). How useful that is depends on the
actual types involved and their representations , but it reflects
existing practice on the vast majority of implementations .
--
Larry Jones

I keep forgetting that rules are only for little nice people. -- Calvin