array elements

Discussion in 'C Programming' started by sophia.agnes@gmail.com, Nov 24, 2007.

  1. Guest

    Hi,

    is there any guarantee that elements of an un initialized array
    by default contains the element 0 ?
     
    , Nov 24, 2007
    #1
    1. Advertising

  2. Ian Collins Guest

    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.
     
    Ian Collins, Nov 24, 2007
    #2
    1. Advertising

  3. <> wrote 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
     
    Malcolm McLean, Nov 24, 2007
    #3
  4. santosh Guest

    In article
    <>,
    <> 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.

    /* 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 */
    /* ... */
    }
     
    santosh, Nov 24, 2007
    #4
  5. Malcolm McLean said:

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


    <grin> Well, 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
     
    Richard Heathfield, Nov 24, 2007
    #5
  6. On Fri, 23 Nov 2007 20:22:31 -0800 (PST),
    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
     
    Barry Schwarz, Nov 25, 2007
    #6
  7. Guest

    On Nov 24, 7:51 pm, Barry Schwarz <> wrote:
    > On Fri, 23 Nov 2007 20:22:31 -0800 (PST),
    > 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?
     
    , Nov 25, 2007
    #7
  8. santosh Guest

    In article
    <>,
    <> wrote on Sunday 25 Nov
    2007 12:37 pm:

    > On Nov 24, 7:51 pm, Barry Schwarz <> wrote:
    >> On Fri, 23 Nov 2007 20:22:31 -0800 (PST),
    >> 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.
     
    santosh, Nov 25, 2007
    #8
  9. Barry Schwarz <> writes:

    > On Fri, 23 Nov 2007 20:22:31 -0800 (PST),
    > 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.
     
    Ben Bacarisse, Nov 25, 2007
    #9
  10. Wade Ward Guest

    "Ian Collins" <> wrote in message
    news:...
    > 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


    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 =----
     
    Wade Ward, Nov 26, 2007
    #10
  11. In article <>,
    Wade Ward <> 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.
     
    Richard Tobin, Nov 26, 2007
    #11
  12. On Sat, 24 Nov 2007 23:07:22 -0800 (PST),
    wrote:

    >On Nov 24, 7:51 pm, Barry Schwarz <> wrote:
    >> On Fri, 23 Nov 2007 20:22:31 -0800 (PST),
    >> 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);
    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
     
    Barry Schwarz, Nov 26, 2007
    #12
  13. Richard Tobin wrote:
    > In article <>,
    > Wade Ward <> 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.
     
    J. J. Farrell, Nov 26, 2007
    #13
  14. On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
    <> wrote:

    >Barry Schwarz <> writes:
    >
    >> On Fri, 23 Nov 2007 20:22:31 -0800 (PST),
    >> 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
     
    Barry Schwarz, Nov 27, 2007
    #14
  15. On Mon, 26 Nov 2007 19:45:00 -0800, Barry Schwarz wrote:
    > On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse <>
    > wrote:
    >>Barry Schwarz <> 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.
     
    Harald van Dijk, Nov 27, 2007
    #15
  16. Barry Schwarz <> writes:

    > On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
    > <> 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 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.
     
    Ben Bacarisse, Dec 5, 2007
    #16
  17. On Wed, 05 Dec 2007 17:31:44 +0000, Ben Bacarisse
    <> wrote:

    >Barry Schwarz <> writes:
    >
    >> On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
    >> <> 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
     
    Barry Schwarz, Dec 8, 2007
    #17
  18. On Sat, 08 Dec 2007 10:22:51 -0800, Barry Schwarz wrote:
    > On Wed, 05 Dec 2007 17:31:44 +0000, Ben Bacarisse <>
    > wrote:
    >
    >>Barry Schwarz <> writes:
    >>
    >>> On Sun, 25 Nov 2007 17:13:53 +0000, Ben Bacarisse
    >>> <> 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.
     
    Harald van Dijk, Dec 8, 2007
    #18
  19. James Kuyper Guest

    Barry Schwarz wrote:
    > On Wed, 05 Dec 2007 17:31:44 +0000, Ben Bacarisse
    > <> 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.
     
    James Kuyper, Dec 9, 2007
    #19
  20. somenath Guest

    On Nov 24, 1:32 pm, santosh <> wrote:
    > In article
    > <>,
    > <> 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);
    }
    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 */
    > /* ... */
    >
    >
    >
     
    somenath, Dec 10, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. diffused
    Replies:
    9
    Views:
    738
    Oscar kind
    Aug 1, 2004
  2. Shalini
    Replies:
    2
    Views:
    509
    Brian Genisio
    Jan 9, 2004
  3. P
    Replies:
    1
    Views:
    1,190
    Joe Kesselman
    Jul 7, 2006
  4. Replies:
    10
    Views:
    686
  5. Arti Singh
    Replies:
    2
    Views:
    143
    Arti Singh
    Jul 26, 2010
Loading...

Share This Page