By definition, valgrind can tell. It handles loading, relocating, and executing the code directly on a synthetic CPU, including all the dynamic libraries used.
If it was not set in this environment, you cannot count on it being set when run natively. This is not lint, or glint, or other static code checkers. This simulates the actual instructions being executed, so any warnings should be looked at carefully. While it is possible for it to make a mistake if you make system calls that it doesn't recognize, any instructions executed outside the kernel will be picked up. There is no place to hide a mechanism. I recommend that anyone who doesn't know what valgrind is take a look at http://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes for a nice explanation of the functioning and limitations. Fuzzy On 8/4/07, Gary Johnson <[EMAIL PROTECTED]> wrote: > I haven't looked at the code referred to by the error messages, but > keep in mind that they may not be real errors. All of the messages > refer to "uninitialised value(s)". In my experience, > correctness-checking programs often report such errors when they > cannot determine for certain that the value of a variable has been > set when in fact it has, but the mechanism is hidden from the > checking program. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
