|
From: <Bor...@pd...> - 2003-08-05 09:07:38
|
And that's the point, in this case valgrind knows, that the access = after this invalid read will cause a Core dump, because you try to access a Null-Pointer and that it should = tell the user. I really think valgrind is as great a memory checker as there is for = free to get, but it needs on some=20 Edges a little bit more work. I'am working in a medium sized firm, and have installed valgrind for = all of our programmers, but some of them would always seek the fault by = someone else, before thinking that they could have made a fault... -----Urspr=FCngliche Nachricht----- Von: Lee Kindness [mailto:lki...@cs...]=20 Gesendet: Dienstag, 5. August 2003 11:02 An: Enders, Borg Cc: lki...@cs...; val...@li... Betreff: AW: [Valgrind-users] core for null pointer access Bor...@pd... writes: > Don't get personal. I'am checking for Null-Pointers in my code...all = I do > here is discuss a hypothetic case. I wasn't, but if your read it that way i'll apologise. > I think like valgrind works now it's not a well defined behavoiur = (one term > you could know out of computer science), and all it should do = is print > something like the following output: >=20 > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? = Continue on > own risk [r/R]?' >=20 > Even a simple message from valgrind like the following would make = the > situation clear: >=20 > 'Your program has caused a memory fault.'=20 >=20 > After such a message every user should know, that It's his bug and = not a > bug of valgrind. >=20 > So to sum up: > My point is: an "Invalid read" followed by a core makes it not = always clear > if this is a bug of valgrind or the tested programm. A short message to the > user before the core is written would make this = situation more > clear. But Valgrind doesn't know that an "Invalid read" will go on to produce = a core dump - many do not. I think a good position would be to assume the bugs are in your code?=20 L. |