|
From: Nick L. <ni...@io...> - 2005-10-18 00:38:13
|
Hi > For that set, it leans in the direction of reporting an error even when > one doesn't exist. The reason is simple: you can usually make it shut up > by adding a few unnecessary initialisations in the right place. The > KDE folks did that, I believe, at some point in the KDE 3.0 line. > Once you've made it shut up, you at least know that your program is > now (probably) safe against use of uninitialised values. Thanks for the response Julian. You're quite correct, and that's the right approach. e.g. the RAND_bytes() function generates errors on the buffer it's filling in, so just memset() the buffer first. No problem with that at all, and a totally standad technique in these cases. The problem as much as anything though was with the value returned from the function that I mentioned in the first post. No amount of assigning to the variable being returned would stop valgrind from reporting the returned value in some cases as uninitialised, and preinitialising to zero the variable accepting the returned value prior to the assignment made no difference either. There were also quite a few reports of memory that wasn't in a known area, i.e. not stack'd, alloc'd etc., but where there was actually no problem at all, and as far as I could tell, a genuine error of a free memory write in libssh2 wasn't caught. On other large projects with the same compiler etc. it's done well though, so who knows? I was surprised, hence the post :) On the reply to the offset issue, there appears to be a confusion over offsets vs. byte counts. In the case of &buf[7], where buf is a buffer of 5 bytes, Purify is correct to say that &buf[7] is 3 bytes beyond the end as it's reporting the byte count. valgrinds report of 2 is really the byte offset, although worded as a count, but if interpreted as an offset then also correct as if we've set a variable 'end' to (beyond) the end of the buffer, &end[2] (offset 2) would be &buf[7] (the 3rd byte relative to the end). Nick |