Self-assignment -- undefined?

[Frederick Gotham]

Does the following snippet exhibit undefined behaviour (excuse the stupidity
of the code):

int i = 5;

i = i;

Or what about a more complex form of it:

void Func(int *const p,int const *const q)
{
*p = *q;
}

int main(void)
{
int i = 5;

Func(&i,&i);

return 0;
}

I'm suspicious that maybe a sequence point is being violated.

--

Frederick Gotham

[Eric Sosman]

Frederick Gotham wrote On 11/09/06 11:24,:

Does the following snippet exhibit undefined behaviour (excuse the stupidity
of the code):

int i = 5;

i = i;

No.

Or what about a more complex form of it:

void Func(int *const p,int const *const q)
{
*p = *q;
}

int main(void)
{
int i = 5;

Func(&i,&i);

return 0;
}

No.

I'm suspicious that maybe a sequence point is being violated.

There's no such thing as "violating a sequence point."
You're probably referring to the rules that require certain
operations -- two modifications to the same object, for
example -- to be separated by at least one sequence point,
but the code snippets above do not break those rules.

--
Er*********@sun.com

[loic-dev]

Hi Frederick,

Does the following snippet exhibit undefined behaviour (excuse the stupidity
of the code):

int i = 5;

i = i;

Or what about a more complex form of it:

void Func(int *const p,int const *const q)
{
*p = *q;
}

int main(void)
{
int i = 5;

Func(&i,&i);

return 0;
}

I'm suspicious that maybe a sequence point is being violated.

For those trivial examples, AFAIK no. Of course, things can become
tricky for instance if your Func assumes different addresses for the
arguments to work correctly.

Cheers,
Loic.

[Kenneth Brody]

lo******@gmx.net wrote:

>
Hi Frederick,

Does the following snippet exhibit undefined behaviour (excuse the stupidity
of the code):

int i = 5;

i = i;

Or what about a more complex form of it:

void Func(int *const p,int const *const q)
{
*p = *q;
}

int main(void)
{
int i = 5;

Func(&i,&i);

return 0;
}

I'm suspicious that maybe a sequence point is being violated.

For those trivial examples, AFAIK no. Of course, things can become
tricky for instance if your Func assumes different addresses for the
arguments to work correctly.

For example, if Func() used:

*p = (*q)++;

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Jordan Abel]

2006-11-09 <1163090289.653296@news1nwk>,
Eric Sosman wrote:

>

Frederick Gotham wrote On 11/09/06 11:24,:

>Does the following snippet exhibit undefined behaviour (excuse the stupidity
of the code):

int i = 5;

i = i;

No.

>Or what about a more complex form of it:

void Func(int *const p,int const *const q)
{
*p = *q;
}

int main(void)
{
int i = 5;

Func(&i,&i);

return 0;
}

No.

>I'm suspicious that maybe a sequence point is being violated.

There's no such thing as "violating a sequence point."
You're probably referring to the rules that require certain
operations -- two modifications to the same object, for
example

or a modification and an access IIRC

-- to be separated by at least one sequence point,
but the code snippets above do not break those rules.

[Eric Sosman]

Jordan Abel wrote On 11/09/06 13:14,:

2006-11-09 <1163090289.653296@news1nwk>,
Eric Sosman wrote:
[...]

> There's no such thing as "violating a sequence point."
You're probably referring to the rules that require certain
operations -- two modifications to the same object, for
example

or a modification and an access IIRC

>>-- to be separated by at least one sequence point,
but the code snippets above do not break those rules.

Depends on nature of the access. 6.5/2:

Between the previous and next sequence point an
object shall have its stored value modified at
most once by the evaluation of an expression.
Furthermore, the prior value shall be read only
to determine the value to be stored.

I've always found that second sentence troubling, because
it seems to ascribe "purpose" or "intent" to the workings
of the abstract machine. "Only to determine" is hard to
read -- for me, anyhow -- in terms of an implementation
rather than in terms of a programmer or implementor. The
programmer has purposes and does things for reasons, but
the implementation just exhibits the behavior the Standard
describes, without intent and without consiousness.

However, there's a footnote that says `i = ++i + 1' and
`a[i++] = i' are undefined while `i = i + 1' and `a[i] = i'
are allowed. The second example seems to be the one that
illustrates the second sentence: `i' is modified, and its
prior value is used in two different ways. As an operand
of `++', the prior value determines the new value (and the
sub-expression value), and this is allowed. The reference
on the r.h.s., though, is not "for the purpose of" computing
the new value, so it's disallowed. The non-normative footnote
conveys the meaning better (to me) than the normative text.

--
Er*********@sun.com

[James Dow Allen]

Frederick Gotham wrote:

Does the following snippet exhibit undefined behaviour ... [?]
[something like *p = *p; ]

The following is *very* OT and perhaps unresponsive
but may be of interest to those curious to hear
about strange machines doing strange things.

<true anecdote>

When the IBM 370 Model 135 or 138 did a memory-to-memory
move (MVC or MVCL opcode) with addresses and counts
all multiples of 8, there are several cases, most of which work
correctly.

However, in the case (which perhaps never happened under
IBM OS'es) that *p1 = *p2 is executed with p1,p2 different
*virtual* addresses which map to the same *real* addresses,
then the data in memory could change! Specifically, a
correctible SBE in the second half of a 8-byte doubleword
could be flipped, i.e. the SBE would be uncorrected and written
back (with check bits no longer reflecting the error.)

Reason: 370 architecture defined such a non-overlapping
MVC or MVCL as "validating". (In the example, real addresses
do overlap, but firmware doesn't detect this.) Things would
still be OK, *except* that, due to a paucity of work registers,
the 135/138 firmware was unable to do
read 8 bytes
write 8 bytes
and instead did
read 4 bytes
write 4 bytes
read 4 bytes
write 4 bytes
The "validation" flag disabled ECC on the first write.

</true anecdote>

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

James D. Allen

[CBFalconer]

James Dow Allen wrote:

>

.... snip ...

>
*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

Nothing unusual about that. Normally discovered by the fact that
the system works fine with a scope probe in place.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Dik T. Winter]

In article <11*********************@f16g2000cwb.googlegroups. com"James Dow Allen" <jd*********@yahoo.comwrites:
....

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

Let me tell you about that multi-million dollar machine that on occasion
would produce wrong result. The reason? A fan mounted the wrong way
around.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Kenneth Brody]

James Dow Allen wrote:
[...]

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

I assume we've all read this entry from the Jargon file:

http://jargon.watson-net.com/section...gic-story.html

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Richard Bos]

"Dik T. Winter" <Di********@cwi.nlwrote:

In article <11*********************@f16g2000cwb.googlegroups. com"James Dow Allen" <jd*********@yahoo.comwrites:
...

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

Let me tell you about that multi-million dollar machine that on occasion
would produce wrong result. The reason? A fan mounted the wrong way
around.

If there are several ways to do something, and one of these ways leads
to disaster, then sooner or later someone _will_ do it that way.

Richard

[Richard Bos]

Kenneth Brody <ke******@spamcop.netwrote:

James Dow Allen wrote:
[...]

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

I assume we've all read this entry from the Jargon file:

http://jargon.watson-net.com/section...gic-story.html

That's not TJF, that's a cheap, CSS-unhanced knock-off. And a slightly
old one, too. _This_ is TJF:

<http://www.catb.org/~esr/jargon/html/magic-story.html>

HTH; HAND.

Richard

[toby]

Richard Bos wrote:

"Dik T. Winter" <Di********@cwi.nlwrote:

In article <11*********************@f16g2000cwb.googlegroups. com"James Dow Allen" <jd*********@yahoo.comwrites:
...

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

Let me tell you about that multi-million dollar machine that on occasion
would produce wrong result. The reason? A fan mounted the wrong way
around.

If there are several ways to do something, and one of these ways leads
to disaster, then sooner or later someone _will_ do it that way.

http://en.wikipedia.org/wiki/Genesis_(spacecraft)

>
Richard

[Kenneth Brody]

Richard Bos wrote:

>
Kenneth Brody <ke******@spamcop.netwrote:

James Dow Allen wrote:
[...]

*Totally* irrelevant I know, but such things seemed very *fun*
for me 30 years ago. Next time I'll tell you about a machine
in Athens, Georgia which failed a silly diagnostic for which
the simplest fix was to place a 100 pF capacitor on a system
clock!

I assume we've all read this entry from the Jargon file:

http://jargon.watson-net.com/section...gic-story.html

That's not TJF, that's a cheap, CSS-unhanced knock-off. And a slightly
old one, too. _This_ is TJF:

<http://www.catb.org/~esr/jargon/html/magic-story.html>

HTH; HAND.

That's what happens when you're lazy and don't take the time to find
"The Real Jargon File"[tm] whereabouts. G may be YF, but it's no
substitute for using your brain. :-)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Charlie Gibbs]

In article <45****************@news.xs4all.nl>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

If there are several ways to do something, and one of these ways leads
to disaster, then sooner or later someone _will_ do it that way.

Sooner or later? It's Microsoft policy.

--
/~\ cg****@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Roland Hutchinson]

Charlie Gibbs wrote:

In article <45****************@news.xs4all.nl>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

>If there are several ways to do something, and one of these ways leads
to disaster, then sooner or later someone _will_ do it that way.

Sooner or later? It's Microsoft policy.

So it will be delivered late.

--
Roland HutchinsonÂ*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*WillÂ*playÂ* violaÂ*daÂ*gambaÂ*forÂ*food.

NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam.Â*Â*IfÂ*yourÂ*messageÂ*looksÂ*likeÂ*spamÂ*IÂ* mayÂ*notÂ*seeÂ*it.

[Michael Roach]

In article <11*********************@e3g2000cwe.googlegroups.c om>,
toby <to**@telegraphics.com.auwrote:

>
Richard Bos wrote:

>"Dik T. Winter" <Di********@cwi.nlwrote:

>
Let me tell you about that multi-million dollar machine that on occasion
would produce wrong result. The reason? A fan mounted the wrong way
around.

If there are several ways to do something, and one of these ways leads
to disaster, then sooner or later someone _will_ do it that way.

http://en.wikipedia.org/wiki/Genesis_(spacecraft)

Somewhere in my wife's lab (and perhaps posted here before) is a sheet
of paper explaining certain phrases that may be found in scientific
papers. To paraphrase a couple:

Results are inconclusive (I dropped it) but some useful results were
found (I scooped up most of it).
--
Frankfort, Kentucky, makes it against the law to shoot off a
policeman's tie.