On Mon, Aug 4, 2008 at 4:23 PM, Guy Harris
<guy@xxxxxxxxxxxx> wrote:
On Aug 4, 2008, at 6:03 AM, Martin Mathieson wrote:
> Unfortunately not. I can't see what is different between this case
> and the one in the built-in packet-ethertype.c which may have been
> used as a template in part for the plugin packet-infiniband.c.
packet-ethertype.c has
tvbuff_t *volatile next_tvb;
in ethertype(), while packet-infiniband.c has
tvbuff_t *next_tvb;
I *really* should've spotted that.
in parse_PAYLOAD(). What happens if you change it to
tvbuff_t *volatile next_tvb;
in parse_PAYLOAD()?
That compiles without warning for me.
(No, I don't know why it's not failing on the Ubuntu buildbot, unless
either
1) you're building for some RISC architecture with more than 16
registers, and next_tvb doesn't end up in a register on x86-64 but
does end up in a register on the architecture for which you're building
Nothing exotic:
ukeng7 martinm main : cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
etc.
or
2) GCC 3.4.6 isn't clever enough to figure out that next_tvb won't
change between the setjmp and longjmp but the version of GCC on the
Ubuntu 7.10 buildbot (my Ubuntu 7.10 virtual machine has a
"prerelease" of GCC 4.1.3) is.)
Would checking in a change to make next_tvb be volatile (or even static, as I had it) be acceptable? (I have no immediate interest in infiniband, and couldn't begin to guess how many people this might affect)
Thanks,
Martin