>int main(void)
>{
> char buf[1000] = malloc(1000;
> buf[0] = 0;
> return 0;
>}
The above program is slightly strange (does not compile here).
But a slightly updated version does also not report a leak.
This is explained by the fact that valgrind does the equivalent of
an "optimistic garbage collection" to find leaks.
So, it is enough that somewhere in memory or in a register, there is
4 bytes (or 8 bytes on a 64 bits) that happens to "point" at an
allocated (not freed) block to have valgrind considering it still
reached.
In my case, it is enough to add another line
buf = malloc (1000);
to have the first block being reported as leaked.
I guess that the pointer to the single (or last) block allocated is
stored in buf but also somewhere else (e.g. maybe in a register).
____
This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender by
reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on
the part of EUROCONTROL, unless it is confirmed by appropriately signed hard
copy.
Any views expressed in this message are those of the sender.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
