On Wednesday 27 June 2001 02:53 am, Jason Spence wrote:
> I've tried this on a Debian Linux box, and tried to make it work on
> cygwin (which I haven't gotten working yet).
>
> for(i = 0; i < BUFSIZE; ++i) {
> for(len = 0; len < 78; ++len) {
> printf("%2x ", buf[i]);
> }
Ok, maybe my C is getting rusty, but doesnt that just print out each byte 78
times? Why the extra for() loop?
> That gives me the weird memory. Had nothing to do with malloc at
> all. I'd like some other people to try the above on different
> systems. I'm particularly interested in getting some hexdumps of the
> data found so I can feed it to a disassembler and figure out if text
> segments are getting allocated.
I tried the above program and was able to see some text strings from my
user's environment, but nothing past that. I will play with it a bit more
and see if I can positively identify the memory that it runs into.
> Also, what is the difference between malloc(3) and calloc(3)? calloc
> says it's supposed to clear the memory, but malloc(3) does that too...
malloc() doesn't clear the memory, it requests a page from the OS, and the OS
may clear that page that the memory is allocated from if it hasnt already
been allocated for that user. So the first malloc of 2k will return clean
memory, but the next malloc of 1k could return memory that has been mucked
with by something else in that process (variables in called functions, libc,
etc). That could be completely wrong technically but thats what I have seen
in practice. I have this fuzzy understanding that pages are normally 4k and
once you have malloc'd more memory then is left in your "current" page, the
OS gives you another (which it then clears). if anyone knows more about the
exact workings of memory and page allocation under linux, windows, and other
OS's I would be great if they shared...
This archive was generated by hypermail 2b30 : Wed Jun 27 2001 - 08:34:06 PDT