Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > address of local parameter

Reply
Thread Tools

address of local parameter

 
 
kerravon
Guest
Posts: n/a
 
      05-24-2013
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.
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      05-24-2013
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'?
 
Reply With Quote
 
 
 
 
kerravon
Guest
Posts: n/a
 
      05-24-2013
On May 25, 3:48*am, James Kuyper <(E-Mail Removed)> 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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-24-2013
kerravon <(E-Mail Removed)> writes:
> On May 25, 3:48*am, James Kuyper <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      05-24-2013
On 05/24/2013 02:21 PM, kerravon wrote:
> On May 25, 3:48 am, James Kuyper <(E-Mail Removed)> 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.6p.
 
Reply With Quote
 
Johann Klammer
Guest
Posts: n/a
 
      05-24-2013
kerravon wrote:
> On May 25, 3:48 am, James Kuyper<(E-Mail Removed)> 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)...

 
Reply With Quote
 
 
 
Reply

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 Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Passing parameter to function not expecting parameter Mister B C Programming 8 08-26-2010 08:01 AM
decltype as a template parameter when containing reference to anothertemplate parameter. Isti C++ 2 04-19-2010 10:01 PM
without declare parameter [double square(parameter)] return 0 in main WanHongbin@gmail.com C Programming 5 10-01-2008 03:31 AM
Using declaration inside first template parameter as default valuefor second template parameter. Stuart Redmann C++ 5 12-14-2007 08:42 AM
Parameter List / Parameter Block / Anything patterns... mast2as@yahoo.com C++ 4 03-29-2007 09:37 PM



Advertisments