|
From: Daniel V. <m4...@ma...> - 2005-12-16 12:58:16
|
I've been using valgrind to check my image compression routine, and reduced the reported problem to the following code, compiled with gcc 4.0.1-4ubuntu9 using "gcc -g -Wall vt.c".
I am not even sure whether valgrind can possibly report the right thing, but here goes:
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
FILE *f;
unsigned char filebuf = 0;
unsigned int refinement_cache; // not initialised
// the following statement works if we turn the plus (+) into an or (|)
refinement_cache = (refinement_cache << 1) + 1; // bit 0 is now valid
f = fopen("vt.tmp", "w");
filebuf = (filebuf << 1) + (refinement_cache & 1); // write bit 0 to file
fwrite(&filebuf, 1, 1, f);
fclose(f); // valgrind complains that we are passing undefined data to a syscall
return 0;
}
|
|
From: Dennis L. <pla...@pr...> - 2005-12-16 15:06:18
|
Am Freitag, den 16.12.2005, 13:58 +0100 schrieb Daniel Vollmer: > I've been using valgrind to check my image compression routine, and reduced the reported problem to the following code, compiled with gcc 4.0.1-4ubuntu9 using "gcc -g -Wall vt.c". > I am not even sure whether valgrind can possibly report the right thing, but here goes: Usually it is correct even on bit-level. maybe the shift&addition is not correctly recognized as defining the bit (well, even the shift should make one bit valid). As valgrind does not know anything about programming languages logic, we would need to look at the generated assembler code. And there I assume that gcc generates something like: movl ...(ebp),eax // move the contents of refinement_cache to eax register addl eax,eax // add those up, leads to the same result as a shift since this is multiplication by two incl eax // do the increase by one movl eax,...(ebp) // store the stuff back So this does first not look like a shift and adding something up looks like undefined when there is just an addition. I assume that in the valgrind instrumentation there is no special case for when the two operands to an addition are the same, which will always lead to one defined bit. maybe this should be fixed, or you can raise a bug for that with the actual assembler code your program generates (I think add -s or -S to gcc will output asm) greets Dennis |