Re: Conditional jump or move depends on uninitialised value(s)

On Wed, 2007-06-27 at 12:29 -0400, Jeffrey Stedfast wrote:
> What's the bug?
> 
> Zeroing the internal buffer doesn't seem like a real fix to me... it
> might silence the valgrind warnings, but nothing seems to check against
> '\0', code only either checks inptr < inend or against inptr !=
> '\n' (inend always gets set to '\n' so there should be no way to compare
> values past the end of the input afaict)
> 
> as far as the other valgrind warnings... well, I can't help but wonder
> if this is actually a gcc optimization bug?
> 
> I don't like the idea of initializing the entire buffer to 0 if it
> doesn't address a real bug because it may end up hiding real bugs.

I think the location was looping the pointer until not '\n'. 

1352	/* goto the next line */
1353	while ((*inptr++)!='\n')
1354		;

I think what valgrind is telling, is that the compare of the value at a
location in inptr with \n was comparing a value that was never touched
or written to (so an undefined value). When allocating with 0, that
would be a '\0'.

It's of course a proposal ... I don't actually know what the code is
supposed to do, I just think the intend of the original programmer, or
rather his assumption, was that inptr is a buffer with '\0''s and data
like '\n' and possibly other characters (a line in a mime part?).

ps. When uninitialised the data might very well contain for example '\n'
characters, and a bug might occur here. So valgrind is probably right
about reporting it.

I agree, though, that I'm assuming a lot. I'd better try to understand
the code, I know :-) (hoping to find some clues here).


> On Wed, 2007-06-27 at 10:57 +0200, Philip Van Hoof wrote:
> > Based on what valgrind is giving me, I'm proposing this patch (attached). 
> > 
> > ==25759== Conditional jump or move depends on uninitialised value(s)
> > ==25759==    at 0x417BB66: folder_scan_content (camel-mime-parser.c:1353)
> > ==25759==    by 0x417C032: folder_scan_step (camel-mime-parser.c:1662)
> > 

-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog