Velocity Reviews > array elements

# array elements

Richard Tobin
Guest
Posts: n/a

 11-26-2007
In article <(E-Mail Removed)>,
Wade Ward <(E-Mail Removed)> wrote:
>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
Guest
Posts: n/a

 11-26-2007
On Sat, 24 Nov 2007 23:07:22 -0800 (PST), http://www.velocityreviews.com/forums/(E-Mail Removed)
wrote:

>On Nov 24, 7:51 pm, Barry Schwarz <(E-Mail Removed)> wrote:
>> On Fri, 23 Nov 2007 20:22:31 -0800 (PST), (E-Mail Removed)
>> 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
Guest
Posts: n/a

 11-26-2007
Richard Tobin wrote:
> In article <(E-Mail Removed)>,
> Wade Ward <(E-Mail Removed)> wrote:
>> 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
Guest
Posts: n/a

 11-27-2007
On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
<(E-Mail Removed)> wrote:

>Barry Schwarz <(E-Mail Removed)> writes:
>
>> On Fri, 23 Nov 2007 20:22:31 -0800 (PST), (E-Mail Removed)
>> 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

Harald van Dĳk
Guest
Posts: n/a

 11-27-2007
On Mon, 26 Nov 2007 19:45:00 -0800, Barry Schwarz wrote:
> On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse <(E-Mail Removed)>
> wrote:
>>Barry Schwarz <(E-Mail Removed)> writes:
>>> 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
Guest
Posts: n/a

 12-05-2007
Barry Schwarz <(E-Mail Removed)> writes:

> On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
> <(E-Mail Removed)> wrote:

<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 Dĳk'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.

Barry Schwarz
Guest
Posts: n/a

 12-08-2007
On Wed, 05 Dec 2007 17:31:44 +0000, Ben Bacarisse
<(E-Mail Removed)> wrote:

>Barry Schwarz <(E-Mail Removed)> writes:
>
>> On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
>> <(E-Mail Removed)> wrote:

><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 D?k'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

Does the standard really require an object to have padding bits in
order for a value to be a trap representation?

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

By this reasoning, if an int of indeterminate value happens to contain
an unspecified value (as opposed to a trap representation), then
accessing that int would not invoke undefined behavior.

By the way, 6.2.6.1-5 insures that all character types, not just
unsigned ones, cannot contain a trap representation.

The point I am trying to make is that the object need not contain a
trap representation for its evaluation to yield undefined behavior.
The undefined behavior is caused by the fact that the value is
indeterminate. Surely no one want to argue that evaluating an
indeterminate 8-bit unsigned char actually leads to one of 256
possible unspecified behaviors.

Remove del for email

Harald van Dĳk
Guest
Posts: n/a

 12-08-2007
On Sat, 08 Dec 2007 10:22:51 -0800, Barry Schwarz wrote:
> On Wed, 05 Dec 2007 17:31:44 +0000, Ben Bacarisse <(E-Mail Removed)>
> wrote:
>
>>Barry Schwarz <(E-Mail Removed)> writes:
>>
>>> On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
>>> <(E-Mail Removed)> wrote:

>><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 D?k'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

>
> Does the standard really require an object to have padding bits in order
> for a value to be a trap representation?

For unsigned integer types, yes. For signed types, the representation
which would correspond to negative zero or -TYPE_MAX-1 (depending on the
representation) is also allowed to be a trap representation. For floating
point or pointer types, trap representations should always be considered
a possibility.

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

>
> By this reasoning, if an int of indeterminate value happens to contain
> an unspecified value (as opposed to a trap representation), then
> accessing that int would not invoke undefined behavior.

Correct. However, when it is unspecified whether the behaviour is
defined, effectively, the behaviour is already undefined.

> By the way, 6.2.6.1-5 insures that all character types, not just
> unsigned ones, cannot contain a trap representation.

Good point. Unfortunately, it doesn't actually say signed/plain char
can't have trap representations. It merely doesn't say the behaviour is
undefined if you read such a trap representation. This means the
behaviour is still undefined by omission if you add 0 to it, for example,
I believe.

> The point I am trying to make is that the object need not contain a trap
> representation for its evaluation to yield undefined behavior. The
> undefined behavior is caused by the fact that the value is
> indeterminate. Surely no one want to argue that evaluating an
> indeterminate 8-bit unsigned char actually leads to one of 256 possible
> unspecified behaviors.

Actually, yes, that's what the standard states as of 1999.

James Kuyper
Guest
Posts: n/a

 12-09-2007
Barry Schwarz wrote:
> On Wed, 05 Dec 2007 17:31:44 +0000, Ben Bacarisse
> <(E-Mail Removed)> wrote:

....
>> To add to Harald van D?k'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

>
> Does the standard really require an object to have padding bits in
> order for a value to be a trap representation?

Not in general. However, the rules for unsigned types require that all
possible bit patterns of the value bits represent valid values.
Therefore, the only way to have a trap representation of an unsigned
type is if there are padding bits. Since unsigned char is not allowed to
have padding bits, this option isn't open.

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

>
> By this reasoning, if an int of indeterminate value happens to contain
> an unspecified value (as opposed to a trap representation), then
> accessing that int would not invoke undefined behavior.

Correct. But, since you have no way of knowing or ensuring that this is
the case when you leave an int uninitialized, it doesn't do you much good.

> By the way, 6.2.6.1-5 insures that all character types, not just
> unsigned ones, cannot contain a trap representation.

No, it merely restricts the undefined behavior that can result from
creating or reading such a representation to non-character types. The
defining characteristic of a trap representation is not the undefined
behavior; it is the fact that it does not "represent a value of the
object type". I find this a meaningless distinction, and probably
contrary to the intent of the authors, but that is what they actually wrote.

somenath
Guest
Posts: n/a

 12-10-2007
On Nov 24, 1:32 pm, santosh <(E-Mail Removed)> wrote:
> In article
> <(E-Mail Removed)>,
> (E-Mail Removed) <(E-Mail Removed)> wrote 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 */
> /* ... */
>
>
>

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Arti Singh Ruby 2 07-26-2010 04:42 PM wenmang@yahoo.com C Programming 10 08-02-2006 04:52 PM P XML 1 07-07-2006 09:08 PM diffused Java 9 08-01-2004 10:09 AM Shalini C++ 2 01-09-2004 06:13 PM

Advertisments