|
From: Ashley P. <as...@qu...> - 2006-01-23 14:11:28
|
On Sat, 2006-01-21 at 03:19 +0000, Julian Seward wrote:
> > {
> > int i = 4;
> > static int j = 5;
> > ELAN_EVENT *e = elan_get(elan_base->state,&j,&i,sizeof(int),0);
> > printf("i is %d\n",i);
> > elan_wait(e,ELAN_POLL_EVENT);
> > printf("i is %d\n",i);
> > }
> >
> > The prototype for elan_get is this, it starts a simple network read:
> > extern ELAN_EVENT *elan_get (ELAN_STATE *state, void *source, void
> > *target, size_t len, uint32_t srcvp);
> >
> > In this code the result of first printf is undefined and the second one
> > will print 5. I was hoping Valgrind could be made to flag an error on
> > the first printf.
>
> I think you're hoping for a bit much. You assigned a value to i
> at the start so it's defined.
>
> But if I read this correctly, elan_get just remembers &i (presumably
> in ELAN_EVENT which is some kind of handle) and writes the actual
> amount of received data there in elan_wait. So why don't you
> start with no value in i - then V will consider it undefined until
> elan_wait writes it.
That's almost right, ELAN_EVENT is a opaque handle and the elan_wait()
call blocks until the data is in &i. In practice &i isn't written to by
either the get() or the wait() call, the data is written by a DMA
running on a remote machine so valgrind will never observe the CPU
setting it. This is why I want to put VALGRIND_MAKE_READABLE() calls in
elan_wait().
The result of the first printf is undefined and will actually vary
between hardware platforms and even different runs of the same program
on the same machine. You're right in that I could just not assign i at
startup however I'm trying to provide an example of a programming bug
that I would like to be able to detect using valgrind, hence my desire
to be able to mark &i it as undefined in elan_get() preferably without
changing the addressability of it.
Ashley,
|