Page 1 of 1
malloc/free extended idea
Posted: Tue Aug 03, 2004 3:45 am
by distantvoices
Recently, this Idea of an extended malloc struck me:
what if we have a bookkeeping structure like this:
mem_chunk:
total_size:integer
next_chunk:pointer_to_mem_chunk
data_start:pointer_to_data
data_field:field_of_required_size
length:size_of_data_field
the total_size field would tell the total size of the allocated chunk+bookkeeping data, data_size only the size of the chunk itself. It would be intrigueing to have string objects in memory knowing their own size in bytes by: object->length. and not only strlen - which only counts til '\0' and sorta.
what do you think about it?
Me personally thinks, it would make functions like itoa or strcpy somewhat safer - if the string objects in question are allocated on the heap.
Re:malloc/free extended idea
Posted: Tue Aug 03, 2004 3:58 am
by Pype.Clicker
problem is that when you're using compiler-generated strings or on-stack object, they won't have the assumed 'header' ...
basically what you suggest is to wrap all Char* into a String ...
Re:malloc/free extended idea
Posted: Tue Aug 03, 2004 4:36 am
by distantvoices
Well, that bugs me too. What to do with objects located on the stack or prelocated by the compiler in some rodata area?
Maybe it is not a so good Idea, is it? Maybe of use in some places, but with limited possibilities.
but it would be nice to have each object know its own size.
Re:malloc/free extended idea
Posted: Tue Aug 03, 2004 5:17 am
by Pype.Clicker
you can do it for *objects*, but not for litterals. Even re-writing the .rodata section wouldn't help as the compiler may decide to make read-only "world" string be the end of read-only "hello world" string (which you'll certainly fail to convert correctly).
Now, nothing prevents you from working with
Code: Select all
struct string {
unsigned size;
char data[]
};
Re:malloc/free extended idea
Posted: Tue Aug 03, 2004 1:17 pm
by proxy
i would just do like i did and implement std::string in kernel land (along with all of the STL
)
it really is more useful than i ever predicted.
proxy
Re:malloc/free extended idea
Posted: Tue Aug 03, 2004 9:59 pm
by Dreamsmith
beyond infinity wrote:mem_chunk:
total_size:integer
next_chunk:pointer_to_mem_chunk
data_start:pointer_to_data
data_field:field_of_required_size
length:size_of_data_field
the total_size field would tell the total size of the allocated chunk+bookkeeping data, data_size only the size of the chunk itself. It would be intrigueing to have string objects in memory knowing their own size in bytes by: object->length. and not only strlen - which only counts til '\0' and sorta.
what do you think about it?
I think it's basically a good idea, but I don't see the reason why you need two seperate size fields. total_size, as you yourself point out, is equal to data_size + size_of_bookkeeping data. No need to waste 4 bytes storing a value you can calculate quickly and easily. Likewise, pointer_to_data should always be equal to the base address of the mem_chunk in question, plus the size of the bookkeeping data. Your idea is good but your implementation is heavy -- you don't need more than 8 bytes (2 ints) of bookkeeping data to implement your idea. You could even do it in 4 (but might not want to, depending on how you plan to optimize for speed).