reassigning pointers

[Chad]

Would reassignig pointers in the following code snippet cause
undefined behavior?

[cdalten@localhost oakland]$ more reassign.c
#include <stdio.h>

int main(void)
{
char *buf;
char x;
x = 5;

buf = &x;
buf = &x;

return 0;
}
[cdalten@localhost oakland]$ gcc -Wall reassign.c -o reassign
[cdalten@localhost oakland]$ ./reassign
[cdalten@localhost oakland]$

 

[Barry Schwarz]

Would reassignig pointers in the following code snippet cause
undefined behavior?
No.


[cdalten@localhost oakland]$ more reassign.c
#include <stdio.h>

int main(void)
{
char *buf;
char x;
x = 5;

buf = &x;
buf = &x;

return 0;
}

 

[Chad]

Chad said:

Would reassignig pointers in the following code snippet cause
undefined behavior?

[cdalten@localhost oakland]$ more reassign.c
#include <stdio.h>

int main(void)
{
char *buf;
char x;
x = 5;

buf = &x;
buf = &x;

return 0;
}

Barry has already answered your question (correctly), but I'm
curious - what made you suspect that the behaviour might be
undefined? If you can answer that, we might be able to improve your
understanding more meaningfully.

On IRC, aka Internet Relay Chat, EFNET channel C++, one of the channel
operators made a passing comment that you couldn't reassign references
in C++ just like how you couldn't reassign pointers in C. So I went
off, wrote some code, and then posted the question here.

Chad

 

[vippstar]

Chad said:

Would reassignig pointers in the following code snippet cause
undefined behavior?
[cdalten@localhost oakland]$ more reassign.c
#include <stdio.h>
int main(void)
{
char *buf;
char x;
x = 5;
buf = &x;
buf = &x;
return 0;
}

Barry has already answered your question (correctly), but I'm
curious - what made you suspect that the behaviour might be
undefined? If you can answer that, we might be able to improve your
understanding more meaningfully.

On IRC, aka Internet Relay Chat, EFNET channel C++, one of the channel
operators made a passing comment that you couldn't reassign references
in C++ just like how you couldn't reassign pointers in C. So I went
off, wrote some code, and then posted the question here.

I don't know about C++, but there's no UB in your code. If you're
curious about what the OP said, you could ask in comp.lang.c++ (NOT
here)

Lastly, the next time some C++ person tells you something about C,
just don't trust them. The C++ channel is for C++, the C is for C.

 

[Tomás Ó hÉilidhe]

On IRC, aka Internet Relay Chat, EFNET channel C++, one of the channel
operators made a passing comment that you couldn't reassign references
in C++ just like how you couldn't reassign pointers in C. So I went
off, wrote some code, and then posted the question here.

Depends whether the pointer is const or not. If it's non-const, you
can change its value til the cows come home.

A reference in C++ is a "const pointer that is always dereferenced".
You can make one in C as follows:

int obj;

int const *p;

#define ref (*p)

Now "ref" behaves exactly like a reference.

Here's a C++ function that takes a reference:

void Func(int &x)
{
x = 4;

if (&x == &some_global_variable)
DoSomething();
}


And here's a C function that pretends it takes a reference:


void Func(int *const px)
{
#define x (*px)

/* From this point forward just use x */

x = 4;

if (&x == &some_global_variable)
DoSomething();
}

 

[vippstar]

Depends whether the pointer is const or not. If it's non-const, you
can change its value til the cows come home.

A reference in C++ is a "const pointer that is always dereferenced".
You can make one in C as follows:

int obj;

int const *p;

#define ref (*p)

Now "ref" behaves exactly like a reference.

No it doesn't, idiot.

Here's a C++ function that takes a reference:

<snip crap>

OP: ignore this fool. He's just a troll.

 

[Harald van Dijk]

On Dec 27, 6:51 am, Tomas the troll <[email protected]> wrote:

No one by that name wrote any message in this thread.

No it doesn't,

In what way does it not?

idiot.

Even if he's wrong (and I'm not convinced he is, because you've done
nothing to try to show it), there's no need for insults.

 

[Ben Pfaff]

No one by that name wrote any message in this thread.


In what way does it not?

For one thing, the "const" is in the wrong place. It should be
after the *, e.g. "int *const p;".

There are numerous other differences, too, of course. One
obvious one is that macros don't obey the scoping rules of
reference types.

 

[vippstar]

No one by that name wrote any message in this thread.

I never claimed he did. I only attributed some words to "Tomas the
troll"

In what way does it not?

In a subtle way that the troll knows and wants us all to waste our
time talking about it. I'm wiser than that.

Even if he's wrong (and I'm not convinced he is, because you've done
nothing to try to show it), there's no need for insults.

Indeed there is not, but I couldn't help it. Even Achilles had a weak
spot.

 

[Harald van Dijk]

For one thing, the "const" is in the wrong place. It should be after
the *, e.g. "int *const p;".

Heh, I missed that. Tomás did get it right later in his function: void
Func(int *const px)

There are numerous other differences, too, of course. One obvious one
is that macros don't obey the scoping rules of reference types.

Well yes, and stringising ref may result in a longer string than expected
depending on how you do it, but I'd assume that differences in
preprocessing were meant to be excluded.

Actually, I can think of one important difference: C's pointer types don't
allow for an equivalent of C++'s const-reference binding to rvalues.

 

[Harald van Dijk]

I never claimed he did. I only attributed some words to "Tomas the
troll"

Which happens to not be the person that wrote those words.

In a subtle way that the troll knows and wants us all to waste our time
talking about it. I'm wiser than that.

How about responding with something nicer, like

"To the OP: there are differences between this and C++'s reference types.
They're not topical here, but if you're interested, the C++ groups can
probably give you the details."

then?

 

[James Kuyper]

Chad wrote:
....

On IRC, aka Internet Relay Chat, EFNET channel C++, one of the channel
operators made a passing comment that you couldn't reassign references
in C++ just like how you couldn't reassign pointers in C. So I went
off, wrote some code, and then posted the question here.

C++ references are, basically, syntactic sugar for const pointers; the
key point here being the 'const' qualifier. His comment is basically
correct about 'const' pointers. If he actually left out 'const', what he
said is nonsense.

 

[CBFalconer]

.... snip ...

In a subtle way that the troll knows and wants us all to waste
our time talking about it. I'm wiser than that.


Indeed there is not, but I couldn't help it. Even Achilles had a
weak spot.

I suggest you practice differentiating between trolls and
youngsters who are not knowledgeable about the usage of C and
c.l.c. The fact that the youngsters are overeager to spread their
misappreciation is not germane. Like most youngsters, they are
quite likely to have weird ideas.

A troll injects off-topic messages to stimulate argument, and amuse
himself. He does not have the least concern for the integrity of
the newsgroup. Twink and McCormack are typical. They often
nymshift to make plonking difficult. Unlike spammers, trolls
actually read the newsgroup.

The same individual may be a troll on some newsgroups, and a useful
participant on others.

 

[David Thompson]

In C++, if you have a variable
char c;
and an initialiser
char& p = c;
followed by an assignment
p = c;

what is the semantics of the initializer, and what is the semantics of
the assignment? Once you figure that out, you know why reassigning the
address of an object to a reference is problematic, and then it will
be obvious why pointers in C++ and C don't have that problem at all.

(Aside from the Undefined Behavior due to reading an uninit object, if
the declaration of c, and thus also p, is block-scope? <G>)

There are easy enough ways to disambiguate the operations.

In Fortran, 'pointer' uses are implicitly dereferenced,
and a different syntax (operator?) is used for reseating.
P = expr changes the target; P => loc changes the pointer.
(In former-Tandem's SIL TAL, now pTAL, pointers are derefed;
P := val changes target and @P := loc changes pointer.)

In Ada, 'access' type is usually implicitly derefed (and can be
explicitly if you prefer), and overload resolution includes expected
type (unlike C++). P = val or P.all = val changes target and P = loc
changes pointer. 'renames' can create an unreseatable reference.
Algol 68 implicitly derefs 'ref' and chooses target or pointer based
on type (except in some weird cases IIRC) for mutable 'ref', and has a
slightly different syntax to create an immutable (but still derefed)
ref. Both similarly call niladic functions without an empty arglist.

C++ refs are unreseatable because BS chose so. It might be addressed
in D&E; my copy is inaccessible for now. AFAIK there hasn't been any
serious desire to change it, because it's not a problem: you can still
do anything reasonable with only minor circumlocutions, such as using
a pointer or an extra local reference (or a few).