malloc/free extended idea

[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.

[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 ...

[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.

[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[]
};

[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

[Dreamsmith]

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).