address of local parameter

K

kerravon

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

James Kuyper

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'?
 
K

kerravon

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

Keith Thompson

kerravon said:
Hi James. Thanks for your reply.


It was in C mode.


A parameter block.

That doesn't help much.
I was referring to the second. Didn't notice the first.


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

James Kuyper

Hi James. Thanks for your reply.


It was in C mode.


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).
I was referring to the second. Didn't notice the first.


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

Johann Klammer

kerravon said:
Hi James. Thanks for your reply.


It was in C mode.


A parameter block.


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


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

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top