pass by address

[Bill Cunningham]

(snip)




I had a compiler that would do that around 1988. (As well as I
remember, both warn and then do the old way.) For some time,
I got used to putting in that extra space.

(My usual convention is not to put space around =, but to put
it around all the compound assignment operators.)


Along with the X'1A', it is plenty long ago enough now.

It wasn't the compiler it was the indent program. It mentioned = &. I
can't seem to remember how to redirect stderr now. And this code works. So I
don't know why people are telling me it doesn't. I think some people are
just playing around with me and lying and trying to confuse me. Well here it
is.

#include <stdio.h>

int main()
{
int a = 15;
int *p;
p = &a;
printf("%p\n", &p);
printf("%p\n", p);
printf("%d\n", *p);
}

The result.

0x7fff8a9bb7b0
0x7fff8a9bb7bc
15

And everytime this is run there is a new addresss used.

Bill

 

[Keith Thompson]

It wasn't the compiler it was the indent program. It mentioned = &.

Surprisingly, GNU indent 2.2.11 does produce a warning for
p=&a;
namely:
Warningld style assignment ambiguity in "=&". Assuming "= &"

Of course you did explicitly say it was the compiler. And you wouldn't
have seen the warning if you had simply copied the code that Lew
suggsted to you without deleting the whitespace.

I can't seem to remember how to redirect stderr now.

You can't copy-and-paste an error message?

And this code
works. So I don't know why people are telling me it doesn't.

I don't recall anyone telling you Lew's code wouldn't work. Here it is,
in its entirety:

int a = 15;
int *p;

p = &a;

printf("%d\n",*p);
scanf("%d\n",p);

I see nothing wrong with it (apart from the poor behavior of scanf on
certain forms of bad input, but that's beside the point).

[...]

 

[Tonton Th]

Undefined behavior #1.


Undefined behavior #2.

I don't understand where in the undefined behaviour. Not so usable
values printed, yes, but &p and p are pointers, so %p can print their
values, no ?

Maybe because p and &p are not 'void *' pointers...

 

[Keith Thompson]

I don't understand where in the undefined behaviour. Not so usable
values printed, yes, but &p and p are pointers, so %p can print their
values, no ?

Maybe because p and &p are not 'void *' pointers...

That's exactly it. "%p" requires an argument of type void*, not of any
arbitrary pointer type. In practice, most implementations use the same
representation and argument passing convention for all pointer types, so
it's likely to work, but for well-defined behavior you need to cast the
arguments to void*.

 

[Bill Cunningham]

That's exactly it. "%p" requires an argument of type void*, not of any
arbitrary pointer type. In practice, most implementations use the same
representation and argument passing convention for all pointer types, so
it's likely to work, but for well-defined behavior you need to cast the
arguments to void*.

Well I learned something today new. I'll keep that in mind. What would
be the best way to take careof that in your opinion? Cast a (void *). These
are the little things that you need to know so when you get into big
programs could cause real problems.

Bill

 

[Bill Cunningham]

Surprisingly, GNU indent 2.2.11 does produce a warning for
p=&a;
namely:
Warningld style assignment ambiguity in "=&". Assuming "= &"

Of course you did explicitly say it was the compiler. And you wouldn't
have seen the warning if you had simply copied the code that Lew
suggsted to you without deleting the whitespace.


You can't copy-and-paste an error message?

It's kind of hard to do at the command line. While I'm typing

indent -kr -nut ...//I have to redirect to do it all in one line.

[...]

 

[Keith Thompson]

Undefined behavior #1.


Undefined behavior #2.


And this surprises you because?

Are you suggesting that the program's output varies because of the
undefined behavior? That's theoretically possible, but very unlikely.

"%p" requires an argument of type void*, the above calls should be
written as:

printf("%p\n", (void*)&p);
printf("%p\n", (void*)p);

But omitting the cast is unlikely to have any *visible* effect on
almost all existing implementations.

If the output varies from one run to the next, it's just because memory
is allocated differently, perhaps by accident or perhaps because of a
deliberate security measure.

http://en.wikipedia.org/wiki/Address_space_layout_randomization

 

[Kaz Kylheku]

That's exactly it. "%p" requires an argument of type void*, not of any
arbitrary pointer type. In practice, most implementations use the same
representation and argument passing convention for all pointer types, so
it's likely to work, but for well-defined behavior you need to cast the
arguments to void*.

For well-defined behavior, you must also avoid the inclusion of
any header which us not in ISO C nor in your program, such as

#include <unistd.h>

Standard-defined behavior is an unrealistic goal for many kinds
of programs. The concept broadly encompasses issues of correctness,
as well as portability.

The assumption that %p can print any pointer is not maximally
portable, that is all.

As a side note, it would be astonishing to find an implementation
where char * arguments break with %p in some way that goes
away when a cast to void * is added.

 

[Barry Schwarz]

Well I learned something today new. I'll keep that in mind. What would

No you didn't. And you probably won't. This is the same advice you
were given as recently as August 20, 2012. Maybe you should consider
saving some of the responses to your messages and rereading them to
reinforce the lessons they provide.

 

[Kaz Kylheku]

For well-defined behavior, you must also avoid the inclusion of
any header which us not in ISO C nor in your program, such as

#include <unistd.h>

Standard-defined behavior is an unrealistic goal for many kinds
of programs. The concept broadly encompasses issues of correctness,
as well as portability.

The assumption that %p can print any pointer is not maximally
portable, that is all.

I'd like to add that you're not really doing a better job of programming
by doing things like printf("%p", (void *) ptr).

You're only wasting time on portability to a machine that you don't have.

If you don't have that machine, you have no way to verify to what
extent you have done a proper job (at least no empirical way).

In other words, portability to hardware that you don't have is half-assed
portability. Not a real portability that actually targets the machine,
and delivers a release for actual deployment somewhere.

Portability to hardware that you don't ever *plan* to have is not
economically justifiable: there is no business case for it.

So, the effort is doubly damned: you're doing a half-assed job of something for
which there is no business case in the first place.

(Kind of like working on a new ISO C standard, isn't it.)

 

[Bill Cunningham]

No you didn't.

No.

And you probably won't.

I won't?

This is the same advice you

were given as recently as August 20, 2012. Maybe you should consider
saving some of the responses to your messages and rereading them to
reinforce the lessons they provide.

I don't know. Things have changed much over two years. I'm not concerned so
much about blah blah 2012. I'm concerned about May 2014. Barry you've got
better things to do. Right?


I don't expect to get into big programs. As said many times (where ya
been?) I am not and don't expect to be a professional C programmer. I just
want to work with a few APIs. But these things you don't get out of a book.
And clc is not a place for a tutorial either. You dont "Teach C" on usenet.

You're smarter than that.

 

[Bill Cunningham]

And this surprises you because?

I'm not suprises at all Barry. Why would I be surprised? I just made a
simple statement. The sun will set today and rise tomorrow.

 

[Barry Schwarz]

Are you for real? You ALSO don't realise you're being trolled?!?!?!
Life can't be fun when so easily made to jump for every treat.

It's obvious he is a troll. So what? It is more entertaining than
the currently never ending thread about Knuth.

 

[Barry Schwarz]

No.

And you probably won't.

I won't?

This is the same advice you

I don't know. Things have changed much over two years. I'm not concerned so
much about blah blah 2012. I'm concerned about May 2014.

Proving once again that George Santayana was right.

I don't expect to get into big programs.

I'm glad you don't. But if you don't, why did you bring it up in the
first place and again now? It is a quote from your message that I
didn't address at all.

 

[Bill Cunningham]

Proving once again that George Santayana was right.

Well I don't know who George Santayana is and don't care. But I'm not
going to get into my personal life with anyone on usenet about anything at
any point in my life. 2, 5, or 20 years ago. But I will say that kandr2
ain't doing it. And I have some more C books now that I didn't have 2 years
ago.

[...]

 

[Bill Cunningham]

Proving once again that George Santayana was right.

Well I don't know who George Santayana is and don't care. But I'm not
going to get into my personal life with anyone on usenet about anything at
any point in my life. 2, 5, or 20 years ago. But I will say that kandr2
ain't doing it. And I have some more C books now that I didn't have 2
years ago.

[...]

Oh yes and let me add too. They seem to have helped me but I will not
mention them because guess what? They're all wrong! Even though the compiler
accepts them and they seem to function!

 

[Malcolm McLean]

Well I learned something today new. I'll keep that in mind. What would
be the best way to take careof that in your opinion? Cast a (void *). These
are the little things that you need to know so when you get into big
programs could cause real problems.

Why do you need to print out a pointer?
I'm sure someone can think of a reason, but normally, only for debugging.
If a program is behaving strangely, you might want to print out a few
pointer values to see what they look like.
So typically you'll insert a daignostic printf("%p\n", ptr), take a
look at the problem, fix it, then delete the code.

 

[Bill Cunningham]

"Malcolm McLean" <[email protected]>

Why do you need to print out a pointer?

I'm sure someone can think of a reason, but normally, only for debugging.
If a program is behaving strangely, you might want to print out a few
pointer values to see what they look like.
So typically you'll insert a daignostic printf("%p\n", ptr), take a
look at the problem, fix it, then delete the code.

In real life I can't think of why. But my tutorials that are no good
give me those examples. There are certain things that you don't pick up out
of the tutorials I now have that you can't get except from those with
experience. The thing is I'm getting a little leary of the advice I'm
getting. It's like asking someone for directions and they point to the right
with the right arm and the left with the left arm and they don't seem to
understand what I just asked.

Bill

 

[Osmium]

The thing is I'm getting a little leary of the advice I'm getting. It's
like asking someone for directions and they point to the right with the
right arm and the left with the left arm and they don't seem to understand
what I just asked.

Is it possible that your writing is sometimes confusing? You do realize
that words such as them, they, those and so on have no intrinsic meaning,
right? So I replaced them by x and updated the grammar so it still reads
like English. .

Do you recognize this?

Oh yes and let me add too. x seems to have helped me but I will not
mention x because guess what? x are all wrong! Even though the compiler
accepts x and x seems to function!

Now what is x? A book? A person? A program fragment? A computer language?
My guess is that there are at least two unknowns, an x and a y. But one
"them" is indistinguishable from another "them", you see a distinction in
your mind, you know what you mean. But that is not very helpful to someone
who can only see the words you type, not see into your mind..

 

[Bill Cunningham]

Is it possible that your writing is sometimes confusing?

Very much so. I can understand that. And it causes some people to accuse
me of saying or doing something I am not. I use contractions alot but I
would think they would be understandable.

Bill