Slightly off-topic, but...

[Nick]

We were discussing earlier today whether a sequence point in something
like "continue;" could make any difference.

While I'm sure it's not that, I'm fascinated by the following output
from gdb on my crashing program:
----
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004422b5 in Real_Evaluate (expr=0x7fffeee62968, cache=0x22afd38,
recurse=false, prevcache=ca_none, lvalue=false, oneitem=false)
at expression.c:520
520 break;

 

[Eric Sosman]

We were discussing earlier today whether a sequence point in something
like "continue;" could make any difference.

I don't see how it could. As far as I can tell, there
will be a sequence point immediately before `continue' in
any context where it can appear. And since `continue' itself
introduces no side-effects, no further sequence point is needed
to separate those non-existent side-effects from whatever is
executed next.

Also, the Standard doesn't appear to specify a sequence
point in or after `continue'.

While I'm sure it's not that, I'm fascinated by the following output
from gdb on my crashing program:
----
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004422b5 in Real_Evaluate (expr=0x7fffeee62968, cache=0x22afd38,
recurse=false, prevcache=ca_none, lvalue=false, oneitem=false)
at expression.c:520
520 break;
----
I'll look at it tomorrow - it's far too late to dig around in core dumps
now, but I'm deeply fascinated by how a "break;" can cause a
segmentation fault, I've never seen anything like it before (the first
thing to do will be to turn optimisation off!).

It's quite likely that the fault occurs "near" the `break',
but that the optimizer's rearrangement of the code disguises
the actual location (we usually sneer at optimizers that give
line boundaries too much deference). I hope for your sake
that the fault is reproducible even with optimization off ...

 

[Nick]

I don't see how it could. As far as I can tell, there
will be a sequence point immediately before `continue' in
any context where it can appear. And since `continue' itself
introduces no side-effects, no further sequence point is needed
to separate those non-existent side-effects from whatever is
executed next.

Also, the Standard doesn't appear to specify a sequence
point in or after `continue'.


It's quite likely that the fault occurs "near" the `break',
but that the optimizer's rearrangement of the code disguises
the actual location (we usually sneer at optimizers that give
line boundaries too much deference). I hope for your sake
that the fault is reproducible even with optimization off ...

It turned out to be terribly boring but a bit strange and inexplicable.
I noticed that as I added printf debugging lines it moved up and down
and didn't reflect the actual changes to the code. I deleted the core
file and let it regenerate itself and it pointed to the actual bug miles
and miles away.