H.Merijn Brand [mailto:[EMAIL PROTECTED]] writes:
> So far, all I got was criticism. I asked for it. But no-one said it was useful. > (Or I didn't read between the lines enough). In my experience, the phrase "I really liked your idea and I hope you won't mind if I share a few ideas for improving it" needs to be inserted before almost anything critical that an engineer says. I've just taken to assuming that the fact that people are giving narrow criticisms is a sign they like the overall picture. And my life is now better for realizing these two truths. :-) Kind of like you have to insert the elided question "How is the quality, performance, and functional completeness of your source code?" before the usual question "When will you be done?" when your boss shows up in your office. ;-) For the record, I think it is useful to be able to obtain the bytesize of a perl object. > Are there systems where the sbrk () value /decreases/ after > mallocs? Top-down stacks and heaps a.o.t. bottom-up. Our OS runs on 3 hardware architectures. On two of them, heaps grow up and stacks grow down. On the PA-RISC, the heap grows down and the stack grows up. The same heap allocator runs on all of them. The heap allocator has exactly one trick to make 'inverted' heaps work; it allocates and then frees the largest possible block. From then on, this humongous free block is carved up by the normal allocation algorithm. The "size" of the inverted heap is a constant value. Our malloc puts a system header before every allocated block that records its size. So, whether you allocate virgin storage or carve up a free block, we can always tell you how big it is. And when you go to free it up, we can verify that it is a pointer to a block of storage that we actually allocated rather than a pointer to random trash. (We also verify that it is still allocated). As I mentioned before, there is no concept of a break address, but you can presume the existance of a subroutine that, given a pointer to a block of malloc'ed storage, can return the number of bytes it occupies. PG
