array elements

[sophia.agnes]

Hi,

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

[Ian Collins]

so**********@gmail.com wrote:

Hi,

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

If there was, it wouldn't be uninitialised!

--
Ian Collins.

[Malcolm McLean]

<so**********@gmail.comwrote in message

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

The implementation sometimes guarantees it. For instance Microsoft's Visual
C used to initialise all memory to 0xC0 in debug, I think to zero in
release - the idea that if an integer with 0xC0C0.... is used as an index it
will generate a large negative vlaue and almost certainly a crash, whilst 0
will probably keep the show on the road.

However it is incorrect to rely on such details.

There are two exceptions.

int array[10000] = {0};

will initialise all elements of array to zero. This is a concession to save
typing.

in global space

/* global */
int array[1000];

void foo(void)
{

}

array is actually initialised to zero, because it is a global. However it is
poor form to rely on this.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[santosh]

In article
<39**********************************@e23g2000prf. googlegroups.com>,
so**********@gmail.com <so**********@gmail.comwrote on Saturday 24
Nov 2007 9:52 am:

Hi,

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

Yes, if it is a static array, the compiler initialises the elements to
zero if no explicit initialisation is provided.

For the case of auto arrays, if you initialise at least one member, the
trailing members are initialised to zero. Otherwise the array has
indeterminate valued elements.

/* file.c */

int arr[10]; /* This is initialised to zero by the compiler/loader */

/* file1.c */

fx()
{
int arr[10] = { 0 }; /* Remaining members are set to zero */
/* ... */
}

[Richard Heathfield]

Malcolm McLean said:

<so**********@gmail.comwrote in message

>is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

The implementation sometimes guarantees it.

<snip>

However it is incorrect to rely on such details.

With you so far...

There are two exceptions.

int array[10000] = {0};

will initialise all elements of array to zero. This is a concession to
save typing.

<grinWell, I suppose you could put it like that. In fact, you could argue
that the standard library is a concession to save typing.

in global space

/* global */
int array[1000];

void foo(void)
{

}

array is actually initialised to zero, because it is a global. However it
is poor form to rely on this.

Here I must disagree. I would argue that it's poor form to use the file
scope object in the first place, but if you're going to do so, I don't see
why it's poor form to rely on the guarantee that ISO gives in its default
static initialiser rule.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Barry Schwarz]

On Fri, 23 Nov 2007 20:22:31 -0800 (PST), so**********@gmail.com
wrote:

>Hi,

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

For a static array or one defined at file scope, if the elements are
integer they contain the VALUE 0. If they are floating point, they
contain 0.0. If they are pointers, they contain NULL. If the
elements are structures, apply the above recursively to the members.
If the elements are unions, ONLY the first member is initialized. They
will all compare equal to zero but need not be represented by all bits
0.

For an automatic array, the guarantee is just the opposite. The
values are indeterminate and any attempt to evaluate an indeterminate
value invokes undefined behavior.
Remove del for email

[sophia.agnes]

On Nov 24, 7:51 pm, Barry Schwarz <[e-mail]:

On Fri, 23 Nov 2007 20:22:31 -0800 (PST), [e-mail]
wrote:

They will all compare equal to zero but need not be represented by all
bits 0.

can you be bit more precise on the above statement.
Do you mean signed zero ?, so that a sign bit 1 is used to represent -
ve values isn't it?

[santosh]

In article
<54**********************************@i12g2000prf. googlegroups.com>,
so**********@gmail.com <so**********@gmail.comwrote on Sunday 25 Nov
2007 12:37 pm:

On Nov 24, 7:51 pm, Barry Schwarz <[e-mail]:

>On Fri, 23 Nov 2007 20:22:31 -0800 (PST), [e-mail]
wrote:

They will all compare equal to zero but need not be represented by all
bits 0.

can you be bit more precise on the above statement.

I suggest that you read the entirety of the following section of the
comp.lang.c FAQ:

<http://c-faq.com/null/index.html>

Also this subject has been discussed innumerable times in this group. A
quick search on Google Groups will turn up a lot links to excellent
previous discussions.

Do you mean signed zero ?, so that a sign bit 1 is used to represent -
ve values isn't it?

No, only for certain architectures.

[Ben Bacarisse]

Barry Schwarz <sc******@doezl.netwrites:

On Fri, 23 Nov 2007 20:22:31 -0800 (PST), so**********@gmail.com
wrote:

>>
is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

<snip>

For an automatic array, the guarantee is just the opposite. The
values are indeterminate and any attempt to evaluate an indeterminate
value invokes undefined behavior.

Nit: except for unsigned char where the values can only be
"unspecified". Unspecified values are always valid for the given
type, so UB does not inevitable follow. Any program that makes use
of this nit is fit only for language lawyering.

--
Ben.

[Wade Ward]

"Ian Collins" <ia******@hotmail.comwrote in message
news:5q*************@mid.individual.net...

so**********@gmail.com wrote:

>Hi,

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

If there was, it wouldn't be uninitialised!

--
Ian Collins.

I'm certain you mean were instead of was. Third person subjunctive present
tense.

Tja.

--
wade ward

wa**@zaxfuuq.net
435 -838-7760

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Richard Tobin]

In article <11*************@sp12lax.superfeed.net>,
Wade Ward <wa**@zaxfuuq.netwrote:

>I'm certain you mean were instead of was. Third person subjunctive present
tense.

The subjunctive is in decline, at least in British English. Not many
people will miss it.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Barry Schwarz]

On Sat, 24 Nov 2007 23:07:22 -0800 (PST), so**********@gmail.com
wrote:

>On Nov 24, 7:51 pm, Barry Schwarz <[e-mail]:

>On Fri, 23 Nov 2007 20:22:31 -0800 (PST), [e-mail]
wrote:

They will all compare equal to zero but need not be represented by all
bits 0.

can you be bit more precise on the above statement.
Do you mean signed zero ?, so that a sign bit 1 is used to represent -
ve values isn't it?

Please configure your newsgroup software to distinguish between what
your are quoting and what you are adding. And then quote enough of
the message you are replying to so the context is clear. Not everyone
is going to remember what "they" stands for.

For a scalar object x of type T which has been initialized with or
assigned a value, you can print the individual bytes that make up the
object with a function like

void hexprint(void *v, size_t n) {
size_t i;
unsigned char *p = v;
for (i = 0; i < n; i++)
printf("%x ", p[i]);
putc('\n');
}

You would call this function with a statement like
hexprint(&x, sizeof x);

If we assume the system uses 8-bit bytes, then for any of the integer
types with a value of 0 the output will be a sequence of 0x00. Using
the terminology in question, an integer value of 0 is represented by
all bits zero. However, this need not be true for floating point and
pointer types. (On my system, one of the many valid representations
of 0.0f is 0x40 0x00 0x00 0x00.) In those cases where it is not true,
the compiler is responsible for ensuring that the code generated for
the expression
x == 0
still evaluates to 1. How it does this is implementation dependent.

The point I was trying to make is that the default initialization for
a static object is performed more in the manner of an assignment
rather than the technique used by calloc.
Remove del for email

[J. J. Farrell]

Richard Tobin wrote:

In article <11*************@sp12lax.superfeed.net>,
Wade Ward <wa**@zaxfuuq.netwrote:

>I'm certain you mean were instead of was. Third person subjunctive present
tense.

The subjunctive is in decline, at least in British English. Not many
people will miss it.

Ah, would that they would.

[Barry Schwarz]

On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
<be********@bsb.me.ukwrote:

>Barry Schwarz <sc******@doezl.netwrites:

>On Fri, 23 Nov 2007 20:22:31 -0800 (PST), so**********@gmail.com
wrote:

>>>
is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

<snip>

>For an automatic array, the guarantee is just the opposite. The
values are indeterminate and any attempt to evaluate an indeterminate
value invokes undefined behavior.

Nit: except for unsigned char where the values can only be
"unspecified". Unspecified values are always valid for the given
type, so UB does not inevitable follow. Any program that makes use
of this nit is fit only for language lawyering.

This makes sense but do you have a reference? 6.2.4-5, 6.2.4-6,
6.7.8-10, and J.2 (bullet 10) don't have any exceptions for unsigned
characters when asserting that accessing an indeterminate value
results in undefined behavior.
Remove del for email

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Mon, 26 Nov 2007 19:45:00 -0800, Barry Schwarz wrote:

On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse <be********@bsb.me.uk>
wrote:

>>Barry Schwarz <sc******@doezl.netwrites:

>>For an automatic array, the guarantee is just the opposite. The
values are indeterminate and any attempt to evaluate an indeterminate
value invokes undefined behavior.

Nit: except for unsigned char where the values can only be
"unspecified". Unspecified values are always valid for the given type,
so UB does not inevitable follow. Any program that makes use of this
nit is fit only for language lawyering.

This makes sense but do you have a reference? 6.2.4-5, 6.2.4-6,
6.7.8-10, and J.2 (bullet 10) don't have any exceptions for unsigned
characters when asserting that accessing an indeterminate value results
in undefined behavior.

J.2 is not normative, and no longer correct. The only possibility for
undefined behaviour for use of an indeterminate value is given by
6.2.6.1p5 (trap representations), and unsigned char isn't allowed to have
trap representations.

This program is also strictly conforming in C99:

#include <limits.h>
int main(void) {
if (INT_MIN == -0x8000
&& INT_MAX == 0x7FFF
&& sizeof(int) * CHAR_BIT == 16)
{
int i;
return !(i | 1);
}
else
return 0;
}

The indeterminate value of i is only read after it is determined that
trap representations are not possible, so 6.2.6.1p5 doesn't apply, so the
behaviour is defined.

[Ben Bacarisse]

Barry Schwarz <sc******@doezl.netwrites:

On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
<be********@bsb.me.ukwrote:

<snip>

>>Nit: except for unsigned char where the values can only be
"unspecified". Unspecified values are always valid for the given
type, so UB does not inevitable follow. Any program that makes use
of this nit is fit only for language lawyering.

This makes sense but do you have a reference?

To add to Harald van Dijk's answer (I am just tidying up marked
messages!), my reasoning follows from 3.17.2 which defines an
indeterminate value as "either an unspecified value or a trap
representation". 6.2.6.2 para. 1 tells us that unsigned char has no
padding bits, so trap representations are not possible. Thus
uninitialised unsigned char variables can only hold, at worst, an
"unspecified value".

Section 3.17.3 defines this as a "valid value of the relevant type
where this International Standard imposes no requirements on which
value is chosen in any instance". Accessing a valid value can't be
the sole cause of undefined behaviour.

--
Ben.

[somenath]

On Nov 24, 1:32 pm, santosh <[e-mail]:

In article
<[e-mail]>,
[e-mail] <[e-mail] on Saturday 24
Nov 2007 9:52 am:

Hi,

is there any guarantee that elements of an un initialized array
by default contains the element 0 ?

Yes, if it is a static array, the compiler initialises the elements to
zero if no explicit initialisation is provided.

For the case of auto arrays, if you initialise at least one member, the
trailing members are initialised to zero. Otherwise the array has
indeterminate valued elements.

I tried with the bellow mentioned code to see the array initialization
working .

#include<stdio.h>
int main(void)
{
int ar[10]= {-1};
int i = 0 ;
for (i = 0 ;i <10 ;i++)
{
printf("\n value of ar[%d] = %d \n",i,ar[i]);
}
return 0;
}

Output of the program

value of ar[0] = -1

value of ar[1] = 0

value of ar[2] = 0

value of ar[3] = 0

value of ar[4] = 0

But I would like to know what the intention behind this kind of
behavior is? Meaning ar[0] = -1 why the other members are
initialized with 0 why not -1 ? What is the idea behind this
behavior?

>
/* file.c */

int arr[10]; /* This is initialised to zero by the compiler/loader */

/* file1.c */

fx()
{
int arr[10] = { 0 }; /* Remaining members are set to zero */
/* ... */