Mailing List Archive

On Fri, Jul 07, 2006 at 05:10:45PM +0200, haypo@inl.fr wrote:
>
> I'm not sure, but I think that a static variable have "undefined value".
> So I don't understand how the code is working without value initialization
> :-)

"The C standard" (not sure exactly which one) specifies that static
variables are initialised to zero.

Cheers,

Phil

--
"This is the first official broadcast of the new Voice of the
Resistance. [...] You can kill us. You can bomb our colonies, destroy our
ships, murder innocent civilians. But you cannot kill the truth. And the
truth is back in business." Ivanova: Babylon 5: Conflicts of Interest

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 7 Jul 2006 17:10, haypo@inl.fr said:

> I'm not sure, but I think that a static variable have "undefined value".
> So I don't understand how the code is working without value initialization

No they are not undefined. They are initialized to zero.

Your patch actually changes the code because the variables are moved
from the BSS to the DATA segment. That is in general not a problem
but it increases the size of the binary.


Shalom-Salam,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

haypo@inl.fr wrote:
> I'm not sure, but I think that a static variable have "undefined value".
> So I don't understand how the code is working without value initialization

This is from C99 but this hasn't changed since C89:

"If an object that has static storage duration is not
initialized explicitly, then:

-- if it has pointer type, it is initialized to a null
pointer;

-- if it has arithmetic type, it is initialized to
(positive or unsigned) zero;

-- if it is an aggregate, every member is initialized
(recursively) according to these rules;

-- if it is a union, the first named member is initialized
(recursively) according to these rules."

--
Christian

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Fri, 07 Jul 2006 17:28:38 +0200,
Werner Koch wrote:
>
> On Fri, 7 Jul 2006 17:10, haypo@inl.fr said:
>
> > I'm not sure, but I think that a static variable have "undefined value".
> > So I don't understand how the code is working without value initialization
>
> No they are not undefined. They are initialized to zero.
>
> Your patch actually changes the code because the variables are moved
> from the BSS to the DATA segment. That is in general not a problem
> but it increases the size of the binary.

Depends on the compiler, though. Recent gcc's are smart enough to put
both in BSS, which means that the old rule "don't initialize static
variables to 0" is somewhat obsolete. In newer code, explicitely
initializing for clarity may be preferred, if you want to.

Gcc's behaviour even makes sense if you don't initialize, because
sometimes initialization to 0 is hidden in macro abstractions.

Oh, and there is still a difference between "int foo = 0;" and "int
foo;". The former allocates a variable in the BSS segment, but the
latter only defines a SHN_COMMON symbol, which is only allocated in
the last linking stage. This allows to put "int foo;" in a header
file that is included by multiple files. Doesn't mix well with
dynamic linking, though...

$ cat > main.c
int foo_noinit;
int foo_init = 0;

main () { printf ("%i %i\n", foo_noinit, foo_init); }
^D
$ make main > /dev/null 2>&1 | objdump --syms main | grep foo
080495a0 g O .bss 00000004 foo_init
080495a4 g O .bss 00000004 foo_noinit

Thanks,
Marcus


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 7 Jul 2006 21:55, Marcus Brinkmann said:

> Oh, and there is still a difference between "int foo = 0;" and "int
> foo;". The former allocates a variable in the BSS segment, but the
> latter only defines a SHN_COMMON symbol, which is only allocated in

However we were talking about static allocation; there it is not the
case.

BTW, common symbols are not defined by the C standard but very common
with most linkers. The RISC OS linker for example don't support them.


Salam-Shalom,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

> On Fri, 7 Jul 2006 17:10, haypo@inl.fr said:
>
>> I'm not sure, but I think that a static variable have "undefined
value". So I don't understand how the code is working without value
>> initialization
>
> No they are not undefined. They are initialized to zero.

Ah ok ;-)

> Your patch actually changes the code because the variables are moved
from the BSS to the DATA segment. That is in general not a problem but it
increases the size of the binary.

So don't apply my patch. I didn't know that.

Victor Stinner
PS: Ooops, I forget to set gnutls-devel@gnupg.org for "To:" email field value





_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel