address of local parameter

Discussion in 'C Programming' started by kerravon, May 24, 2013.

  1. kerravon

    kerravon Guest

    I found that it was necessary to put a "static" below:

    static int testGenericBlockDeviceRequest(void)
    {
    int ret;
    int x;
    int y;
    static PB_1560 parm_block;
    char *p=&parm_block;

    Why is that? And why didn't the compiler (TC++ 1.01)
    complain about it if it is wrong?

    Thanks. Paul.
    kerravon, May 24, 2013
    #1
    1. Advertising

  2. kerravon

    James Kuyper Guest

    On 05/24/2013 01:12 PM, kerravon wrote:
    > I found that it was necessary to put a "static" below:
    >
    > static int testGenericBlockDeviceRequest(void)
    > {
    > int ret;
    > int x;
    > int y;
    > static PB_1560 parm_block;
    > char *p=&parm_block;
    >
    > Why is that? And why didn't the compiler (TC++ 1.01)
    > complain about it if it is wrong?


    TC++ 1.01 sounds like a C++ compiler. That's OK if you were using it in
    a mode where it was working as a C compiler; otherwise, you're likely to
    get better answers to your question in comp.lang.c++.

    PB_1560 is presumably a typedef. What is a typedef for?

    There's two different occurrences of 'static' in that code. Which one
    are you referring to?

    If the compiler didn't complain, then you reached the conclusion that
    'static' was needed based upon some evidence other than a compiler error
    message. What was that evidence?

    With an appropriate typedef of PB_1560, either or both of the
    occurrences of 'static' could be removed from your code, and it could
    still be part of a perfectly reasonable program, which is probably why
    your compiler didn't complain. Of course, removing either one would
    change the meaning of the program, and that difference in meaning could
    cause problems, but that depends upon what the rest of your program does
    with testGenericBlockDeviceRequest(). What was the problem you had,
    which you fixed by inserting 'static'?
    James Kuyper, May 24, 2013
    #2
    1. Advertising

  3. kerravon

    kerravon Guest

    On May 25, 3:48 am, James Kuyper <> wrote:
    > On 05/24/2013 01:12 PM, kerravon wrote:
    >
    > > I found that it was necessary to put a "static" below:

    >
    > > static int testGenericBlockDeviceRequest(void)
    > > {
    > >     int ret;
    > >     int x;
    > >     int y;
    > >     static PB_1560 parm_block;
    > >     char *p=&parm_block;

    >
    > > Why is that? And why didn't the compiler (TC++ 1.01)
    > > complain about it if it is wrong?

    >


    Hi James. Thanks for your reply.

    > TC++ 1.01 sounds like a C++ compiler. That's OK if you were using it in
    > a mode where it was working as a C compiler; otherwise, you're likely to
    > get better answers to your question in comp.lang.c++.


    It was in C mode.

    > PB_1560 is presumably a typedef. What is a typedef for?


    A parameter block.

    > There's two different occurrences of 'static' in that code. Which one
    > are you referring to?


    I was referring to the second. Didn't notice the first.

    > If the compiler didn't complain, then you reached the conclusion that
    > 'static' was needed based upon some evidence other than a compiler error
    > message. What was that evidence?


    There are various times when you can't take the
    address of a variable, and I don't know all the
    rules, so just guessed.

    But now I have found out the real problem. The
    PB was too small and stack variables got wiped
    out, but I didn't realise that was happening.

    I have removed the static now and it works fine.

    Thanks. Paul.
    kerravon, May 24, 2013
    #3
  4. kerravon <> writes:
    > On May 25, 3:48 am, James Kuyper <> wrote:
    >> On 05/24/2013 01:12 PM, kerravon wrote:
    >>
    >> > I found that it was necessary to put a "static" below:

    >>
    >> > static int testGenericBlockDeviceRequest(void)
    >> > {
    >> >     int ret;
    >> >     int x;
    >> >     int y;
    >> >     static PB_1560 parm_block;
    >> >     char *p=&parm_block;

    >>
    >> > Why is that? And why didn't the compiler (TC++ 1.01)
    >> > complain about it if it is wrong?

    >>

    >
    > Hi James. Thanks for your reply.
    >
    >> TC++ 1.01 sounds like a C++ compiler. That's OK if you were using it in
    >> a mode where it was working as a C compiler; otherwise, you're likely to
    >> get better answers to your question in comp.lang.c++.

    >
    > It was in C mode.
    >
    >> PB_1560 is presumably a typedef. What is a typedef for?

    >
    > A parameter block.


    That doesn't help much.

    >> There's two different occurrences of 'static' in that code. Which one
    >> are you referring to?

    >
    > I was referring to the second. Didn't notice the first.
    >
    >> If the compiler didn't complain, then you reached the conclusion that
    >> 'static' was needed based upon some evidence other than a compiler error
    >> message. What was that evidence?

    >
    > There are various times when you can't take the
    > address of a variable, and I don't know all the
    > rules, so just guessed.


    The only case I know of that you *can't* take the address of a variable
    is when it's defined with the "register" keyword. (I'm assuming that a
    "variable" is a named object that's not a subobject of something else;
    you also can't take the address of a bit field.)

    There are cases where you can't safely *use* the address of an
    object, particularly after the object has ceased to exist. An object
    declared with "static" continues to exist as long as the program
    is executing; an object defined inside a function without "static"
    ceases to exist on completion of the innermost block containing the
    definition. Returning the address of a non-static local object,
    or otherwise making the address available after the function has
    returned, is a common error. Your code looks like it *could* be
    part of an example like that, but without knowing what you do with
    "p" it's impossible to tell.

    > But now I have found out the real problem. The
    > PB was too small and stack variables got wiped
    > out, but I didn't realise that was happening.
    >
    > I have removed the static now and it works fine.


    It's still possible that it *appears* to "work fine", but your
    code's behavior is undefined. It's not possible to tell without
    more information (probably in the form of more complete code).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 24, 2013
    #4
  5. kerravon

    James Kuyper Guest

    On 05/24/2013 02:21 PM, kerravon wrote:
    > On May 25, 3:48 am, James Kuyper <> wrote:
    >> On 05/24/2013 01:12 PM, kerravon wrote:
    >>
    >>> I found that it was necessary to put a "static" below:

    >>
    >>> static int testGenericBlockDeviceRequest(void)
    >>> {
    >>> int ret;
    >>> int x;
    >>> int y;
    >>> static PB_1560 parm_block;
    >>> char *p=&parm_block;

    >>
    >>> Why is that? And why didn't the compiler (TC++ 1.01)
    >>> complain about it if it is wrong?

    >>

    >
    > Hi James. Thanks for your reply.
    >
    >> TC++ 1.01 sounds like a C++ compiler. That's OK if you were using it in
    >> a mode where it was working as a C compiler; otherwise, you're likely to
    >> get better answers to your question in comp.lang.c++.

    >
    > It was in C mode.
    >
    >> PB_1560 is presumably a typedef. What is a typedef for?

    >
    > A parameter block.


    I was actually asking for the C data type that describes that parameter
    block. Unless that data type is compatible with 'char', you should have
    gotten a diagnostic message from the initialization of 'p' (6.5.16.1p1).

    >> There's two different occurrences of 'static' in that code. Which one
    >> are you referring to?

    >
    > I was referring to the second. Didn't notice the first.
    >
    >> If the compiler didn't complain, then you reached the conclusion that
    >> 'static' was needed based upon some evidence other than a compiler error
    >> message. What was that evidence?

    >
    > There are various times when you can't take the
    > address of a variable, and I don't know all the
    > rules, so just guessed.


    There is a restriction, but in only applies if 'p' has static or thread
    storage duration. In that case, the initializer for 'p' must be an
    address constant or a string literal (6.7.9p4). &parm_block is an
    address constant only if parm_block has static storage duration (6.6p8).
    James Kuyper, May 24, 2013
    #5
  6. kerravon wrote:
    > On May 25, 3:48 am, James Kuyper<> wrote:
    >> On 05/24/2013 01:12 PM, kerravon wrote:
    >>
    >>> I found that it was necessary to put a "static" below:

    >>
    >>> static int testGenericBlockDeviceRequest(void)
    >>> {
    >>> int ret;
    >>> int x;
    >>> int y;
    >>> static PB_1560 parm_block;
    >>> char *p=&parm_block;

    >>
    >>> Why is that? And why didn't the compiler (TC++ 1.01)
    >>> complain about it if it is wrong?

    >>

    >
    > Hi James. Thanks for your reply.
    >
    >> TC++ 1.01 sounds like a C++ compiler. That's OK if you were using it in
    >> a mode where it was working as a C compiler; otherwise, you're likely to
    >> get better answers to your question in comp.lang.c++.

    >
    > It was in C mode.
    >
    >> PB_1560 is presumably a typedef. What is a typedef for?

    >
    > A parameter block.
    >
    >> There's two different occurrences of 'static' in that code. Which one
    >> are you referring to?

    >
    > I was referring to the second. Didn't notice the first.
    >
    >> If the compiler didn't complain, then you reached the conclusion that
    >> 'static' was needed based upon some evidence other than a compiler error
    >> message. What was that evidence?

    >
    > There are various times when you can't take the
    > address of a variable, and I don't know all the
    > rules, so just guessed.
    >
    > But now I have found out the real problem. The
    > PB was too small and stack variables got wiped
    > out, but I didn't realise that was happening.
    >
    > I have removed the static now and it works fine.
    >
    > Thanks. Paul.


    1) There may be problems, if your struct is too large for the allocated
    stack space.... common in DOS etc... Linux has a default of 8MBytes, so
    less of an issue, I think... There's compiler/linker switches to change
    stack size...

    2) There may be problems trying to return a pointer to data on the
    stack. Data gets overwritten on later function calls... malloc() any
    memory you want to return pointers to.

    3) The uninitialized static vars tend to end up in the BSS section of
    the program(on that kind of box that you code on). That tends to get
    initialized to zero. The stack will contain values from previous
    operations. If you neglect to initialize the relevant fields, you will
    also get bugs(when using stack, but not when static)...
    Johann Klammer, May 24, 2013
    #6
    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. avnrao
    Replies:
    1
    Views:
    7,223
    avnrao
    May 4, 2004
  2. Patrice
    Replies:
    0
    Views:
    883
    Patrice
    May 4, 2004
  3. Raterus
    Replies:
    0
    Views:
    435
    Raterus
    Jun 2, 2004
  4. Alex Stevens
    Replies:
    0
    Views:
    778
    Alex Stevens
    Aug 10, 2004
  5. =?Utf-8?B?QW5nZWw=?=

    Pass a Web Address and return a File System Address

    =?Utf-8?B?QW5nZWw=?=, Sep 20, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    536
    =?Utf-8?B?U3RldmUgQy4gT3Jy?=
    Sep 21, 2005
Loading...

Share This Page