passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer

[jimjim]

#include <stdio.h>
#include <stdlib.h>

//WARNING: The function's signature should be: f( int ** )
void f(int *ip) {
static int dummy = 5;
*ip = &dummy;
}

int main(){
int *ip;
f(&ip);
printf("%d",*ip);
return 0;
}

The function's signature should be: f( int ** ). However, f( int *) seems to
produce the same results, even though I am
warned by the compiler (Borland_bcc_5.5):
Warning W8069 solution.c 5: Nonportable pointer conversion in function f
Warning W8075 solution.c 12: Suspicious pointer conversion in function main

What can go wrong when you pass the address of a pointer to a function that
does not recieve a pointer to a pointer?

TIA
jimjim

 

[Michael Mair]

#include <stdio.h>
#include <stdlib.h>

//WARNING: The function's signature should be: f( int ** )
void f(int *ip) {
static int dummy = 5;
*ip = &dummy;
}

int main(){
int *ip;
f(&ip);
printf("%d",*ip);
return 0;
}

The function's signature should be: f( int ** ). However, f( int *) seems to
produce the same results, even though I am
warned by the compiler (Borland_bcc_5.5):
Warning W8069 solution.c 5: Nonportable pointer conversion in function f
Warning W8075 solution.c 12: Suspicious pointer conversion in function main

What can go wrong when you pass the address of a pointer to a function that
does not recieve a pointer to a pointer?

The above seems to "work" by pure, dumb luck or bad luck.
It works, if
1) the representation of an int** is the same as for an int*
2) the conversion address->int->address yields the original
address
3) an int* can be stored in an int (this can hold if the size
of an int* is the same as the size of an int).
This is just a rough description, not by the very word of the
standard. This means, it can easily break or sometimes break
if sizeof (int*) != sizeof (int) which is not that unlikely
in the future if you think of 64 bit architectures.

Just do not do that.


Cheers
Michael

 

[pete]

jimjim wrote:

What can go wrong when you pass
the address of a pointer to a function that
does not recieve a pointer to a pointer?

Whatever might be caused by the function translation
not taking into consideration that you may have
passed in the wrong type.

The philosophy of the newsgroup,
is that it is worth knowing how to write defined code,
and not worth knowing just exactly
what might happen with undefined code.

 

[Barry Schwarz]

#include <stdio.h>
#include <stdlib.h>

//WARNING: The function's signature should be: f( int ** )
void f(int *ip) {
static int dummy = 5;
*ip = &dummy;

As a result of the faulty calling statement, this statement invokes
undefined behavior. One of the more insidious manifestations of
undefined behavior is to "appear to work as intended." Just bad luck.
Not the worst luck (it could have formatted your hard drive) or good
luck (an easily diagnosed software failure).

}

int main(){
int *ip;
f(&ip);
printf("%d",*ip);
return 0;
}

The function's signature should be: f( int ** ). However, f( int *) seems to
produce the same results, even though I am
warned by the compiler (Borland_bcc_5.5):
Warning W8069 solution.c 5: Nonportable pointer conversion in function f
Warning W8075 solution.c 12: Suspicious pointer conversion in function main

Ignore the warnings if you want but you really need to understand ALL
the repercussions.

What can go wrong when you pass the address of a pointer to a function that
does not recieve a pointer to a pointer?

Let's just consider your code and a system that requires an int to be
aligned on a four-byte boundary. When you return from f, ip contains
the address 5. Your printf statement says go to address 5 and extract
the value of the int that is there. What will the hardware do when it
attempts to extract an int that is not aligned properly.

What about systems where an int and an address do not share the same
representation. If you code something like
int *ptr;
ptr = (int*)dummy;
the compiler knows you are converting an int to a pointer and can
generate the code to to perform the conversion properly. In your
code, the compiler believes you assigning an int value to an int and
sees no need for any conversion. The value in ip might be a trap
representation (that would be good luck).


Remove del for email

 

[SM Ryan]

# What can go wrong when you pass the address of a pointer to a function that
# does not recieve a pointer to a pointer?

You can use any type T for int* such that sizeof(T)=sizeof(int*). If you cast,
you will avoid compiler warnings.

On most implementations sizeof(int)=sizeof(T*) and in the early days of
unix many interfaces were based on that. If you need to do this, and this
is not just stupid C pet tricks, be sure to test to sizeof assumption in
main() start up or in the installer.

 

[Keith Thompson]

# What can go wrong when you pass the address of a pointer to a function
# that does not recieve a pointer to a pointer?

The question was posted by "jimjim" <[email protected]>.
Please don't snip attributions. And *please* stop using your stupid
'#' quoting character. You've been told repeatedly that it causes
problems for some newsreaders; your stubbornness on this point is why
I usually ignore anything you post.

You can use any type T for int* such that sizeof(T)=sizeof(int*). If
you cast, you will avoid compiler warnings.

On most implementations sizeof(int)=sizeof(T*) and in the early days of
unix many interfaces were based on that. If you need to do this, and this
is not just stupid C pet tricks, be sure to test to sizeof assumption in
main() start up or in the installer.

Casting to suppress compiler warnings is dangerous and foolish.
Parameters of different types can be passed by different mechanisms,
even if they're the same size. For example, some systems might use
different sets of registers for pointers vs. integers, or integers
vs. floating-point types. If both types are pointers, there's
probably less risk of something going visibly wrong, but the behavior
is still undefined. Don't waste time figuring out how it can go
wrong; just fix the code.

 

[CBFalconer]

The question was posted by "jimjim" <[email protected]>.
Please don't snip attributions. And *please* stop using your
stupid '#' quoting character. You've been told repeatedly that
it causes problems for some newsreaders; your stubbornness on
this point is why I usually ignore anything you post.

Many of us no longer notice him, we just let the plonk file work.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[jimjim]

What can go wrong when you pass the address of a pointer to a function

The above seems to "work" by pure, dumb luck or bad luck.
It works, if
1) the representation of an int** is the same as for an int*
2) the conversion address->int->address yields the original
address
3) an int* can be stored in an int (this can hold if the size
of an int* is the same as the size of an int).
This is just a rough description, not by the very word of the
standard. This means, it can easily break or sometimes break
if sizeof (int*) != sizeof (int) which is not that unlikely
in the future if you think of 64 bit architectures.

Hi..thx to all for your replies!

As far as your (1) point is concerned, I understand it.
Now, your (2) point hints that theres a relationship btw pointer
representation of an address and int(s). Can you elaborate on that, please?
Regarding your (3) point, how does an int* and an int relates to my code's
use of an int* as an int**? Can you elaborate, please?

TIA

 

[Vladimir S. Oka]

jimjim opined:

Hi..thx to all for your replies!

As far as your (1) point is concerned, I understand it.
Now, your (2) point hints that theres a relationship btw pointer
representation of an address and int(s). Can you elaborate on that,

2) says that your code will work if converting from the pointer to
`int` and back to the pointer, yields the same pointer you started
with. This is going to be implementation-specific, so you can't really
count on that being true.

please? Regarding your (3) point, how does an int* and an int relates
to my code's use of an int* as an int**? Can you elaborate, please?

It would be possible to reply to that, but you did not quote the code
in question, and I can't see your OP. You also snipped attribution
lines (the ones saying "jimjim opined:" or similar), soI don't really
know who you're replying to.

TIA

These have been slated recently, and for good reasons, IMHO.

 

[santosh]

jimjim opined:

It would be possible to reply to that, but you did not quote the code
in question, and I can't see your OP. You also snipped attribution
lines (the ones saying "jimjim opined:" or similar), soI don't really
know who you're replying to.

Here's a reconstruction of the thread, as far as I can see:

 

[SM Ryan]

# The question was posted by "jimjim" <[email protected]>.
# Please don't snip attributions. And *please* stop using your stupid
# '#' quoting character. You've been told repeatedly that it causes
# problems for some newsreaders; your stubbornness on this point is why
# I usually ignore anything you post.

Now I'm scared. Please, please, don't netkop me.

# Casting to suppress compiler warnings is dangerous and foolish.
# Parameters of different types can be passed by different mechanisms,
# even if they're the same size. For example, some systems might use
# different sets of registers for pointers vs. integers, or integers

If your compiler is incapable of moving values into correct registers
during a cast, you desperately need a new compiler.

 

[santosh]

Now I'm scared. Please, please, don't netkop me.


If your compiler is incapable of moving values into correct registers
during a cast, you desperately need a new compiler.

The whole point of a cast is to force a compiler to do what you want it
to do, in which case it might very well end up storing values in
registers not suited for their types, and giving rise to undefined
behaviour. That is why it's advisable to use a cast only after
understanding the ramifications, (which might mean looking up
implementation specific behaviour), and when it's use is essential to
the code in question.

 

[Keith Thompson]

If your compiler is incapable of moving values into correct registers
during a cast, you desperately need a new compiler.

Ok, the differences in parameter passing applies mostly in cases where
a call is performed with no prototype in scope.

The original code has a function that takes a parameter of type int*,
and calls it with an argument of type int**. The compiler quite
correctly complained (it's a constraint violation, so it's required to
do so).

The solution is to fix either the function or the call so the types
are consistent. Casting the int** argument to int* will (probably)
silence the warning, and won't cause problems with parameter passing
mechanisms. The only problem is that the result of converting the
int** value to int* is unlikely to be meaningful.

The OP asked what can go wrong; you advised him to hide the problem
with a meaningless cast.

 

[Rod Pemberton]

# The question was posted by "jimjim" <[email protected]>.
# Please don't snip attributions. And *please* stop using your stupid
# '#' quoting character. You've been told repeatedly that it causes
# problems for some newsreaders; your stubbornness on this point is why
# I usually ignore anything you post.

Now I'm scared. Please, please, don't netkop me.

Keith. How can you criticize him for "#" when you use "]" on occasion?

 

[Keith Thompson]

# The question was posted by "jimjim" <[email protected]>.
# Please don't snip attributions. And *please* stop using your stupid
# '#' quoting character. You've been told repeatedly that it causes
# problems for some newsreaders; your stubbornness on this point is why
# I usually ignore anything you post.

Now I'm scared. Please, please, don't netkop me.

Keith. How can you criticize him for "#" when you use "]" on occasion?

I use "]" only when I'm quoting something that doesn't come directly
from the parent article; using ">" in that context could be
misleading. I've never heard of any newsreader having problems with
"]" (if you know of one that does, please let me know). Multiple
people have said that "#" does cause problems. It can be argued that
that's a bug in those newsreaders, but I see no point in deliberately
and repeatedly triggering that bug. (In my own newsreader, it's not
much of a problem, except that the command to re-fill a paragraph
doesn't recognize a leading "#" as a quoting character; it does
recognize both ">" and "]".)

SM Ryan has been asked repeatedly why he insists on using "#"; he has
never answered. I can only assume he's being deliberately obnoxious,
which is why I usually ignore him. (I usually try to ignore you as
well, but this was actually a reasonable question.)

 

[Mark McIntyre]

SM Ryan has been asked repeatedly why he insists on using "#"; he has
never answered.

Actually, I recall that he did. He said at one point that he'd written
his own newsreader and deliberately designed it to use this character
for quotes for an unknown reason. When challenged, he got stroppy and
said everyone else's s/w was broken. Go figure...

Mark McIntyre

 

[Jordan Abel]

# The question was posted by "jimjim" <[email protected]>.
# Please don't snip attributions. And *please* stop using your stupid
# '#' quoting character. You've been told repeatedly that it causes
# problems for some newsreaders; your stubbornness on this point is why
# I usually ignore anything you post.

Now I'm scared. Please, please, don't netkop me.

Keith. How can you criticize him for "#" when you use "]" on occasion?

I use "]" only when I'm quoting something that doesn't come directly
from the parent article;

I use | for that purpose, it works better in my newsreader.

using ">" in that context could be misleading. I've never heard of
any newsreader having problems with "]" (if you know of one that does,
please let me know).

My editor doesn't allow me to easily reflow text with quote markers
other than > and # by default. However, I have altered the default
setting, and I may alter it further.

Multiple people have said that "#" does cause problems. It can be
argued that that's a bug in those newsreaders, but I see no point in
deliberately and repeatedly triggering that bug.

Which newsreaders are those? Mine doesn't color either # or ] properly,
but I could change that if i cared. oddly, it recognizes = as a quote
marker.

(In my own newsreader, it's not much of a problem, except that the
command to re-fill a paragraph doesn't recognize a leading "#" as
a quoting character; it does recognize both ">" and "]".)

SM Ryan has been asked repeatedly why he insists on using "#"; he has
never answered. I can only assume he's being deliberately obnoxious,
which is why I usually ignore him. (I usually try to ignore you as
well, but this was actually a reasonable question.)

What _does_ it break? It's hard to imagine what that could break, other
than people whining that it doesn't format it as a blockquote in their
gui newsreaders. Do non-quoted lines beginning in # also break them? in
that case, how does it know the difference? What i'm saying is, does it
actually _break_ them, or does it somehow fail to be recognized as
quoted text, and if the latter, is that really worth caring about?

If the newsreader really breakes, like, crashes, or fails to display, on
lines beginning in #, that is a serious bug in the newsreader and there
are much more serious problems than people using it as a quote marker.
If it just doesn't format it or color it or do other special things
based on it being quoted text, that's not really worth giving a crap
about IMO.