Array memory allocation

Discussion in 'C++' started by Pallav singh, Dec 17, 2007.

  1. Pallav singh

    Pallav singh Guest

    Hi

    if i declare globally its get store id BSS / Data
    segment .................with size a.out we can verify
    where does array is allocated memory when its declared inside a
    function ......... i only see a change a little bit in Text ( Code )
    Segment Size only

    Thanks
    Pallav Singh


    #include<stdio.h>

    char p[40];
    static double d;

    int i = 10;
    static long l = 20;

    int main()
    {

    int arr[1000] = {0};
    int array[1000] = {0};

    int i =3 , j ,*ip;
    ip=(int *)malloc(sizeof(i));

    p[5] = i;
    d = 2.0 * 20;
    return 0;

    }
     
    Pallav singh, Dec 17, 2007
    #1
    1. Advertising

  2. On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh wrote:
    > where does array is allocated memory when its declared
    > inside a function


    The stack.

    --
    Joel Yliluoma - http://iki.fi/bisqwit/
     
    Joel Yliluoma, Dec 17, 2007
    #2
    1. Advertising

  3. Pallav singh

    Rahul Guest

    On Dec 17, 2:33 pm, Joel Yliluoma <> wrote:
    > On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh wrote:
    > > where does array is allocated memory when its declared
    > > inside a function

    >
    > The stack.
    >
    > --
    > Joel Yliluoma -http://iki.fi/bisqwit/


    Only when the actual function is called...
     
    Rahul, Dec 17, 2007
    #3
  4. Pallav singh

    Jack Klein Guest

    On Mon, 17 Dec 2007 02:13:09 -0800 (PST), Rahul <>
    wrote in comp.lang.c++:

    > On Dec 17, 2:33 pm, Joel Yliluoma <> wrote:
    > > On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh wrote:
    > > > where does array is allocated memory when its declared
    > > > inside a function

    > >
    > > The stack.


    What stack? Can you cite a reference from the C++ language standard
    that requires or guarantees the existence of such a stack?

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 18, 2007
    #4
  5. Pallav singh

    Jack Klein Guest

    On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh
    <> wrote in comp.lang.c++:

    > Hi
    >
    > if i declare globally its get store id BSS / Data
    > segment .................with size a.out we can verify


    The '.' key on your keyboard seems to be broken. In English, there
    are places where a single '.' character is used, after an abbreviation
    or at the end of a sentence. And there are places where an ellipsis
    is used, which is exactly three '.' characters, like this: ...

    There is no place in the English language where two or four or
    seventeen continuous '.' characters has any meaning at all.

    As for your assertion, maybe your particular C++ compiler has things
    called "BSS" or "Data" segments. The C++ language has no such things,
    leaving the details up to the compiler.

    > where does array is allocated memory when its declared inside a
    > function ......... i only see a change a little bit in Text ( Code )
    > Segment Size only


    Automatic objects allocated inside a function go wherever the compiler
    implementer decided to put them. The C++ language does not specify.

    If you want to know how your particular compiler does these things,
    ask in a group that discusses your specific compiler.

    > Thanks
    > Pallav Singh


    If your compiler accepts the code below, either it is completely
    broken, or perhaps it is a C compiler. The code is ill-formed for
    C++.

    > #include<stdio.h>


    <stdio.h> is deprecated in C++ in favor of <cstdio>.

    > char p[40];
    > static double d;
    >
    > int i = 10;
    > static long l = 20;
    >
    > int main()
    > {
    >
    > int arr[1000] = {0};
    > int array[1000] = {0};
    >
    > int i =3 , j ,*ip;
    > ip=(int *)malloc(sizeof(i));


    There is no declaration in scope for malloc(), because you have not
    included <cstdlib> or even <stdlib.h>. A conforming C++ compiler will
    not accept a call to a function without a proper declaration in scope.

    The cast will allow older C compilers, prior to the 1999 version of
    the C standard, to accept the code without a diagnostic. For versions
    of the C standard from 1999 later, calling a function without a
    declaration is a constraint violation.

    In all versions of C and C++, this code is just plain wrong, and
    produces undefined behavior.

    > p[5] = i;
    > d = 2.0 * 20;
    > return 0;
    >
    > }


    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 18, 2007
    #5
  6. Pallav singh

    James Kanze Guest

    On Dec 18, 5:30 am, Jack Klein <> wrote:
    > On Mon, 17 Dec 2007 02:13:09 -0800 (PST), Rahul <>
    > wrote in comp.lang.c++:


    > > On Dec 17, 2:33 pm, Joel Yliluoma <> wrote:
    > > > On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh wrote:
    > > > > where does array is allocated memory when its declared
    > > > > inside a function


    > > > The stack.


    > What stack? Can you cite a reference from the C++ language
    > standard that requires or guarantees the existence of such a
    > stack?


    §3.7.2 seems clear enough to me; §5.2.2/9 makes it even more
    explicit. You can't implement C++ without a stack. (It's true
    that in the special case of main, an implementation is not
    required to allocate local variables on the stack.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 18, 2007
    #6
  7. Pallav singh

    James Kanze Guest

    On Dec 18, 5:39 am, Jack Klein <> wrote:
    > On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh
    > <> wrote in comp.lang.c++:


    > > if i declare globally its get store id BSS / Data
    > > segment .................with size a.out we can verify


    > The '.' key on your keyboard seems to be broken. In English,
    > there are places where a single '.' character is used, after
    > an abbreviation or at the end of a sentence. And there are
    > places where an ellipsis is used, which is exactly three '.'
    > characters, like this: ...


    > There is no place in the English language where two or four or
    > seventeen continuous '.' characters has any meaning at all.


    Sure there are. When lining up data in tables and such, for
    example. LaTeX has constructions for generating it, for example
    (and it's fairly easy to do in C++, by setting fill to '.' in
    the output stream).

    Of course, that may not be what the poster is trying to do here.

    > As for your assertion, maybe your particular C++ compiler has
    > things called "BSS" or "Data" segments. The C++ language has
    > no such things, leaving the details up to the compiler.


    They never the less seem to be pretty commonly used terms for
    the memory holding initialized and uninitialized (or zero
    initialized) objects with static lifetimes.

    > > where does array is allocated memory when its declared
    > > inside a function ......... i only see a change a little bit
    > > in Text ( Code ) Segment Size only


    > Automatic objects allocated inside a function go wherever the
    > compiler implementer decided to put them. The C++ language
    > does not specify.


    The semantics of the language do require some sort of a stack,
    however (except for the special cas of main). What's
    implementation defined is how the compiler implements this
    stack.

    > If you want to know how your particular compiler does these
    > things, ask in a group that discusses your specific compiler.


    > If your compiler accepts the code below, either it is
    > completely broken, or perhaps it is a C compiler. The code is
    > ill-formed for C++.


    > > #include<stdio.h>


    > <stdio.h> is deprecated in C++ in favor of <cstdio>.


    Bof. It's not going to disappear anytime soon.

    Of course, since he doesn't use anything from the header, the
    best solution is to drop the include completely. (Maybe he
    miscopied, and his actual code included <stdlib.h> instead.)

    > > char p[40];
    > > static double d;


    > > int i = 10;
    > > static long l = 20;


    > > int main()
    > > {


    > > int arr[1000] = {0};
    > > int array[1000] = {0};


    > > int i =3 , j ,*ip;
    > > ip=(int *)malloc(sizeof(i));


    > There is no declaration in scope for malloc(), because you
    > have not included <cstdlib> or even <stdlib.h>. A conforming
    > C++ compiler will not accept a call to a function without a
    > proper declaration in scope.


    > The cast will allow older C compilers, prior to the 1999
    > version of the C standard, to accept the code without a
    > diagnostic. For versions of the C standard from 1999 later,
    > calling a function without a declaration is a constraint
    > violation.


    Older C compilers will accept it, but will do the wrong thing
    with it. If no definition is in scope, the compiler will assume
    that malloc returns an int (not a void*). The cast will convert
    this int to a pointer. On machines where int's and pointers
    don't have the same size (e.g. the original 16 bit x86's, and
    most modern 64 bit machines), this will definitely cause
    problems, and even on machines where they are the same size,
    there's no guarantee that it works.

    It's precisely problems like this that causes Stroustrup to
    invent function prototypes, and the C standards committee to
    adopt them. Although C doesn't require them, in order to avoid
    breaking existing code, I would imagine that most C compilers
    would at least warn if there was no prototype in scope.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 18, 2007
    #7
  8. Pallav singh

    bjarne Guest

    On Dec 18, 2:56 am, James Kanze <> wrote:

    >
    > It's precisely problems like this that causesStroustrupto
    > invent function prototypes, and the C standards committee to
    > adopt them. Although C doesn't require them, in order to avoid
    > breaking existing code, I would imagine that most C compilers
    > would at least warn if there was no prototype in scope.
    >


    I'm sorry have to accuse you of being an optimist. I tried this with
    GCC 3.4.3:

    // x.c:
    void f(int i)
    {
    printf("%d\n",i);
    }

    // y.c:
    int main()
    {
    f("asdfg");
    return 0;
    }

    Neither f() nor printf() has a prototype in scope. Since printf() is
    variadic, it is required to have a prototype in scope, but the
    compiler doesn't *know* that printf() is variadic.

    It compiled without any warnings and a.out gave the result 67432.

    I guess I have to be patient. It's only 25 years since I started to
    use function declarations for checking in C with Classes and only just
    over 20 years since I started to enforce them across translation unit
    boundaries in C++.

    Maybe in another decade, we can rely on C compilers doing this by
    default. Until then, we can select our C compilers and their options
    with care, not make such mistakes, or use C++.

    -- Bjarne Stroustrup
     
    bjarne, Dec 19, 2007
    #8
  9. Pallav singh

    Ian Collins Guest

    bjarne wrote:
    > On Dec 18, 2:56 am, James Kanze <> wrote:
    >
    >> It's precisely problems like this that causesStroustrupto
    >> invent function prototypes, and the C standards committee to
    >> adopt them. Although C doesn't require them, in order to avoid
    >> breaking existing code, I would imagine that most C compilers
    >> would at least warn if there was no prototype in scope.
    >>

    >
    > I'm sorry have to accuse you of being an optimist. I tried this with
    > GCC 3.4.3:
    >
    > // x.c:
    > void f(int i)
    > {
    > printf("%d\n",i);
    > }
    >
    > // y.c:
    > int main()
    > {
    > f("asdfg");
    > return 0;
    > }
    >
    > Neither f() nor printf() has a prototype in scope. Since printf() is
    > variadic, it is required to have a prototype in scope, but the
    > compiler doesn't *know* that printf() is variadic.
    >
    > It compiled without any warnings and a.out gave the result 67432.
    >

    That's because you invokes it as a "gcc default C like language"
    compiler, rather than a compliant C compiler!

    gcc /tmp/x.c /tmp/y.c -ansi -Wall -pedantic
    /tmp/x.c: In function `main':
    /tmp/x.c:4: warning: implicit declaration of function `f'
    /tmp/y.c: In function `f':
    /tmp/y.c:3: warning: implicit declaration of function `printf'

    --
    Ian Collins.
     
    Ian Collins, Dec 19, 2007
    #9
  10. Ian Collins wrote:
    > bjarne wrote:
    >> On Dec 18, 2:56 am, James Kanze <> wrote:
    >>
    >>> It's precisely problems like this that causesStroustrupto
    >>> invent function prototypes, and the C standards committee to
    >>> adopt them. Although C doesn't require them, in order to avoid
    >>> breaking existing code, I would imagine that most C compilers
    >>> would at least warn if there was no prototype in scope.
    >>>

    >>
    >> I'm sorry have to accuse you of being an optimist. I tried this with
    >> GCC 3.4.3:
    >>
    >> // x.c:
    >> void f(int i)
    >> {
    >> printf("%d\n",i);
    >> }
    >>
    >> // y.c:
    >> int main()
    >> {
    >> f("asdfg");
    >> return 0;
    >> }
    >>
    >> Neither f() nor printf() has a prototype in scope. Since printf() is
    >> variadic, it is required to have a prototype in scope, but the
    >> compiler doesn't *know* that printf() is variadic.
    >>
    >> It compiled without any warnings and a.out gave the result 67432.
    >>

    > That's because you invokes it as a "gcc default C like language"
    > compiler, rather than a compliant C compiler!
    >
    > gcc /tmp/x.c /tmp/y.c -ansi -Wall -pedantic
    > /tmp/x.c: In function `main':
    > /tmp/x.c:4: warning: implicit declaration of function `f'
    > /tmp/y.c: In function `f':
    > /tmp/y.c:3: warning: implicit declaration of function `printf'


    C does not require a function prototype to exist. What you have here
    are _warnings_, Bjarnes code is well-formed C, AFAICS. If you have
    a doubt, do ask in 'c.l.c'.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 19, 2007
    #10
  11. Pallav singh

    Ian Collins Guest

    Victor Bazarov wrote:
    > Ian Collins wrote:
    >> bjarne wrote:
    >>> On Dec 18, 2:56 am, James Kanze <> wrote:
    >>>
    >>>> It's precisely problems like this that causesStroustrupto
    >>>> invent function prototypes, and the C standards committee to
    >>>> adopt them. Although C doesn't require them, in order to avoid
    >>>> breaking existing code, I would imagine that most C compilers
    >>>> would at least warn if there was no prototype in scope.
    >>>>
    >>> I'm sorry have to accuse you of being an optimist. I tried this with
    >>> GCC 3.4.3:
    >>>
    >>> // x.c:
    >>> void f(int i)
    >>> {
    >>> printf("%d\n",i);
    >>> }
    >>>
    >>> // y.c:
    >>> int main()
    >>> {
    >>> f("asdfg");
    >>> return 0;
    >>> }
    >>>
    >>> Neither f() nor printf() has a prototype in scope. Since printf() is
    >>> variadic, it is required to have a prototype in scope, but the
    >>> compiler doesn't *know* that printf() is variadic.
    >>>
    >>> It compiled without any warnings and a.out gave the result 67432.
    >>>

    >> That's because you invokes it as a "gcc default C like language"
    >> compiler, rather than a compliant C compiler!
    >>
    >> gcc /tmp/x.c /tmp/y.c -ansi -Wall -pedantic
    >> /tmp/x.c: In function `main':
    >> /tmp/x.c:4: warning: implicit declaration of function `f'
    >> /tmp/y.c: In function `f':
    >> /tmp/y.c:3: warning: implicit declaration of function `printf'

    >
    > C does not require a function prototype to exist. What you have here
    > are _warnings_, Bjarnes code is well-formed C, AFAICS. If you have
    > a doubt, do ask in 'c.l.c'.
    >

    I don't, it isn't well formed. Calling a variadic without a declaration
    in scope invokes our old friend undefined behaviour. That's why the
    compiler is required to issue a diagnostic in conforming mode.

    I wasn't commenting on the code, I was pointing out that by default gcc
    (like most other C compilers) isn't a conforming C compiler, you have to
    tell it to use a conforming mode.

    The fact that C only requires a diagnostic and the compiler is free to
    carry on and produce an executable is one of the many reasons I prefer
    C++ to C!

    --
    Ian Collins.
     
    Ian Collins, Dec 19, 2007
    #11
  12. Pallav singh

    James Kanze Guest

    On Dec 19, 11:24 pm, Ian Collins <> wrote:
    > Victor Bazarov wrote:


    > > C does not require a function prototype to exist. What you
    > > have here are _warnings_, Bjarnes code is well-formed C,
    > > AFAICS. If you have a doubt, do ask in 'c.l.c'.


    I thought someone said they were required in C99. However, the
    discussion was about warnings---I simply assumed that any C++
    compiler worth its salt would *warn* about implicit function
    declarations, since it is such an obvious source of error.
    Apparently, as Bjarne pointed out, I was being overly
    optimistic.

    > I don't, it isn't well formed. Calling a variadic without a
    > declaration in scope invokes our old friend undefined
    > behaviour. That's why the compiler is required to issue a
    > diagnostic in conforming mode.


    CAlling a variadic function without a declaration in scope
    invokes undefined behavior. Which means that anything the
    compiler does is fine. No diagnostic required. (FWIW: I did
    use a C compiler once which generated bad code in such
    cases---it used different calling conventions for variadic
    functions than for normal functions. Of course, it was for
    embedded systems in a free standing environment, with almost no
    standard library, so previously existing code wasn't an issue.)

    > I wasn't commenting on the code, I was pointing out that by
    > default gcc (like most other C compilers) isn't a conforming C
    > compiler, you have to tell it to use a conforming mode.


    IMHO, this is one warning that should be on by default. It's
    been how many years now that function prototypes exist?

    > The fact that C only requires a diagnostic and the compiler is
    > free to carry on and produce an executable is one of the many
    > reasons I prefer C++ to C!


    There's actually no difference between C and C++ in this regard.
    In the case of undefined behavior, anything goes. In cases
    where a diagnostic is required, anything the implementation
    documents is a diagostic (and gcc/g++ documents that all
    messages issued by the compiler can be considered diagnostics in
    the sense of the standard), and once the diagnositic is issued,
    what happens next is undefined. As in undefined behavior: most
    compilers will try to give a more or less readable message, and
    not generate an object file, in the case of an error. But most
    will also consider at least some warnings as "diagnostics", and
    generate code despite what the standard says is an error, and a
    compiler which just output a "?" and reformatted your hard disk
    would be fully conforming (but probably not a large success
    commercially).

    (Note too that a compiler is allowed to issue a diagnostic even
    when no error is present. So a compiler which always output a
    "?", and always generated an object file with something in it,
    would also be fully conforming, as long as the contents of the
    object file were correct when there was no error.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 20, 2007
    #12
  13. Pallav singh

    Default User Guest

    Victor Bazarov wrote:

    > Ian Collins wrote:


    > > gcc /tmp/x.c /tmp/y.c -ansi -Wall -pedantic
    > > /tmp/x.c: In function `main':
    > > /tmp/x.c:4: warning: implicit declaration of function `f'
    > > /tmp/y.c: In function `f':
    > > /tmp/y.c:3: warning: implicit declaration of function `printf'

    >
    > C does not require a function prototype to exist.


    Depends on what you mean. Use of a variadic function like printf()
    without a prototype in scope is undefined behavior. It doesn't require
    a diagnostic.





    Brian
     
    Default User, Dec 20, 2007
    #13
  14. Pallav singh

    Default User Guest

    Ian Collins wrote:

    > Victor Bazarov wrote:


    > > C does not require a function prototype to exist. What you have
    > > here are warnings, Bjarnes code is well-formed C, AFAICS. If you
    > > have a doubt, do ask in 'c.l.c'.
    > >

    > I don't, it isn't well formed. Calling a variadic without a
    > declaration in scope invokes our old friend undefined behaviour.


    No, more strictive, it requires a prototype. C still allows function
    declarations like:

    int printf();

    > That's why the compiler is required to issue a diagnostic in
    > conforming mode.


    I don't think that's true. Now, for a C99 compiler, use of any function
    without a declaration requires a diagnostic. Implicit declarations went
    away.





    Brian
     
    Default User, Dec 20, 2007
    #14
  15. Pallav singh

    Default User Guest

    James Kanze wrote:

    > On Dec 19, 11:24 pm, Ian Collins <> wrote:
    > > Victor Bazarov wrote:

    >
    > > > C does not require a function prototype to exist.


    > I thought someone said they were required in C99.


    No, declarations are required, but not prototypes. However, "old style"
    is obsolescent.

    > However, the
    > discussion was about warnings---I simply assumed that any C++
    > compiler worth its salt would warn about implicit function
    > declarations, since it is such an obvious source of error.


    I assume you mean C compiler. For C++ that's a required diagnostic (and
    for C99 as well).

    > Apparently, as Bjarne pointed out, I was being overly
    > optimistic.


    In fact, it did warn when in conforming mode, right?





    Brian
     
    Default User, Dec 20, 2007
    #15
  16. Pallav singh

    James Kanze Guest

    On Dec 20, 6:37 pm, "Default User" <> wrote:
    > Ian Collins wrote:
    > > Victor Bazarov wrote:
    > > > C does not require a function prototype to exist. What you have
    > > > here are warnings, Bjarnes code is well-formed C, AFAICS. If you
    > > > have a doubt, do ask in 'c.l.c'.


    > > I don't, it isn't well formed. Calling a variadic without a
    > > declaration in scope invokes our old friend undefined behaviour.


    > No, more strictive, it requires a prototype. C still allows function
    > declarations like:


    > int printf();


    Not in this case. Even C90 requires a function prototype to be
    in scope when a variadic function is called. Something like the
    above would result in undefined behavior if you used printf in
    the code.

    For non-variadic functions, of course, C90 didn't even require a
    declaration if the function, at least if it returned int. And
    most C compilers seem to use the C90 rules by default.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 21, 2007
    #16
    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. s.subbarayan

    Dynamic memory allocation and memory leak...

    s.subbarayan, Mar 18, 2005, in forum: C Programming
    Replies:
    10
    Views:
    720
    Eric Sosman
    Mar 22, 2005
  2. Rodrigo Dominguez

    memory allocation and freeing memory

    Rodrigo Dominguez, Jun 13, 2005, in forum: C Programming
    Replies:
    11
    Views:
    616
    Jean-Claude Arbaut
    Jun 15, 2005
  3. Ken
    Replies:
    24
    Views:
    3,902
    Ben Bacarisse
    Nov 30, 2006
  4. chris
    Replies:
    6
    Views:
    1,007
    chris
    Oct 28, 2005
  5. Bjarke Hammersholt Roune
    Replies:
    14
    Views:
    1,208
    Bjarke Hammersholt Roune
    Mar 6, 2011
Loading...

Share This Page