Some help on application dev

[PeterX]

I'm writing an application with needs a dynamic, linked list of medium-sized [roughly 256 or 264 bytes] entries and a few rather big memory blocks [of varying size upto 4K each].
I'm writing in C on Linux.

Should I use malloc()? Or is there in C a way to allocate variables dynamically (like in C++)?

I thought of a linked list containing entries with this struct:

Code: Select all

struct i_file{
void *next;
char filename[256];
};

[Octocontrabass]

Use malloc(), and also define your link pointer as "struct i_file *next" instead of "void *next".

Note that malloc() does not initialize the allocated memory's contents. Depending on what you're going to put in that memory, you might want to use calloc() instead.

(Or just use C++.)

[mkfree]

Talking about malloc, free, ...

Actually these functions are nothing more than calls to get memory from the heap, it is an area
that is assigned from the kernel itself to the application generally after the bss,
it is not even initialized, that is, when it is used, a failure occurs
of page, the kernel assigns it a physical page and that's when this memory really exists
physically.
I give you an example in "C" they are usually called malloc, free, ... and they are in the stdlib.h library, this
it is a way of maintaining the standard. Already in c ++ the new and delete operators are used.

I give you an example from the beginning:

In c you can define it in the stdio.h library or wherever you decide, the only important thing here is to know
the kernel call that returns the start of the heap, is usually called with sbrk () as standard
and you can implement your own malloc, free or whatever name you decide.


there is a place where you define these functions to be used in c ++

Code: Select all

// For new operator example int * val = new int;
void * operator new (u32 len) {
    malloc (len);
}

// For new operator example int * val = new int [10]
void * operator new [] (u32 len) {
    return :: operator new (len);
}

// for delete (val) operators

void operator delete (void * ptr) {
    free (ptr);
}

// for delete operators (val [5])
void operator delete [] (void * ptr) {
    :: operator delete (ptr);
}

I give you an example when you create for example in c ++
int * new = new int [20]
actually c ++ ends up calling malloc

If you need a deeper detail I can help you, I really had to do all the
implementations to implement the libraries my kernel uses.

I hope these words serve you and help you. Regards

[dseller]

Should I use malloc()?

Yes.

Or is there in C a way to allocate variables dynamically (like in C++)?

malloc is the way to allocate memory in C.

[bzt]

malloc is the way to allocate memory in C.

Yes. Except when you only need to allocate local memory, then you can also use alloca. The difference is,
- malloc allocates memory in the dynbss section, so you can return the allocated buffer to the caller, while
- alloca just decreases the stack pointer, thus being much faster O(1), but the buffer gets lost when the function returns to the caller.

This also means that malloc buffers has to be explicitly freed, while alloca buffers are automatically freed in the function epilogue.

Cheers,
bzt

[mkfree]

Yes you can use malloc, always remember to free the memory when you are not using it to avoid an increase in the consumption of RAM memory by your application.

[PeterX]

Thanks to all of you. With your help I managed to solve my issue.

And the fact that the memory has to be freed, is indeed an inportant information. (I did it anyway but I thought it was just good style and not neccessary!)

Greetings
Peter

[thewrongchristian]

Thanks to all of you. With your help I managed to solve my issue.

And the fact that the memory has to be freed, is indeed an inportant information. (I did it anyway but I thought it was just good style and not neccessary!)

Greetings
Peter

Or using GC:

https://en.wikipedia.org/wiki/Boehm_garbage_collector

To anyone that scoffs at the idea of GC in C, if you can do the GC at times you're otherwise idle, you can potentially improve performance (as you're not longer incurring a cost for free()), as well as making your code safer.

[mkfree]

Let me tell you something else, really when you free up memory it does not mean that the occupied RAM decreases, but when you request memory again this freed area can be used by your application without the need to increase the heap. In other words, the heap cannot be reduced, but expanded. When your application is terminated by the kernel then everything is released.
Regards

[Octocontrabass]

really when you free up memory it does not mean that the occupied RAM decreases,

That depends on the heap allocator implementation. If you have a system call like mmap(), it's entirely possible for your allocator to release freed memory back to the OS. Whether it's a good idea to do that is another matter: you probably want to avoid releasing memory that's just going to be allocated again.

[mkfree]

Octocontrabass,
100% agree.

[PeterX]

really when you free up memory it does not mean that the occupied RAM decreases,

That depends on the heap allocator implementation. If you have a system call like mmap(), it's entirely possible for your allocator to release freed memory back to the OS. Whether it's a good idea to do that is another matter: you probably want to avoid releasing memory that's just going to be allocated again.

In the case of my application the memory is not freed and then allocated again.
I don't understand yet what mmap() does. I guess it is because I still don't understand paging fully. (Okay, I have some idea about paging, but I don't comprehend it in detail.)

And does mmap() exist on every generic OS? Is it part of the C standard library?

[nexos]

mmap is not in the standard C library. I believe it is a part of POSIX. It is a system call, and allows you to map files and memory, can figure out a virtual address to allocate or have you specify one, it can set readable and writeable attributes, plus more. It is a very good function, but it allocates in pages. On x86, that means 4K blocks of memory. It is generally better to use malloc, and when you need granular control over the memory or when mapping a file or when you know the virtual address you want to use, then mmap is your friend. Just note that is not portable. I believe Windows uses VirtualAlloc or MapViewOfFile instead.

[PeterX]

mmap is not in the standard C library. I believe it is a part of POSIX. It is a system call, and allows you to map files and memory, can figure out a virtual address to allocate or have you specify one, it can set readable and writeable attributes, plus more. It is a very good function, but it allocates in pages. On x86, that means 4K blocks of memory. It is generally better to use malloc, and when you need granular control over the memory or when mapping a file or when you know the virtual address you want to use, then mmap is your friend. Just note that is not portable. I believe Windows uses VirtualAlloc or MapViewOfFile instead.

Well, it's bad that it is not portable to Windows. But it sounds cool.
Does it mean, I can map a file to memory without reading the bytes in one-by-one? That would come very handy for my project.

[nexos]

Yes, you can! It uses demand paging, so it reads the file data on demand to save memory. Info about demand paging can be found at https://en.wikipedia.org/wiki/Demand_paging.