«

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

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.

--

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.

loic- 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: <private.php?do=newpm&u=>

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.

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.

--

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

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>

In article <. com> "James Dow Allen" <> writes:
....
> *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, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

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: <private.php?do=newpm&u=>