Visual overview of a custom malloc() implementation
silent-tower.net
Visual overview of a custom malloc() implementation
1–10 of 31 posts
Re: Visual overview of a custom malloc() implementation
#2Excellent, very well written.
Re: Visual overview of a custom malloc() implementation
#3Why are the letters ’p’, ’q’ and ’t’ missing from the article? Makes it a bit annoying to read.
Re: Visual overview of a custom malloc() implementation
#4This was very good!
I was really happy when the first code on the page, for once, did not look like it was written by someone writing C when they would much rather write something else.
This line:
struct article *my_article = malloc(sizeof *my_article);
- Does not use a pointless, wordy, bloated cast to somehow "convert" the pointer to the proper type. The point of malloc() returning a void pointer is that no such cast is needed.
- Does not hardcode a size, but uses the sizeof operator to let the compiler compute it.
- Does not repeat the type name, which is brittle and wordy, but instead (again) lets the compiler compute it from the target pointer.
I was a bit more hesitant about this line, later in the article:
return (void *)b + sizeof(block_t) + b->size;
Re: Visual overview of a custom malloc() implementation
#5Unfortunately the author is violating POSIX here by defining his own _t types, which is a suffix reserved for the system. Too bad since everyone likes it.
Re: Visual overview of a custom malloc() implementation
#6Unfortunately the author is violating POSIX here by defining his own _t types, which is a suffix reserved for the system. Too bad since everyone likes it.
Also unfortunate are the use of a heap segment representation, and sbrk.
Re: Visual overview of a custom malloc() implementation
#7Why are the letters ’p’, ’q’ and ’t’ missing from the article? Makes it a bit annoying to read.
I think this might be a client-side issue, since I can see those letters normally.
Re: Visual overview of a custom malloc() implementation
#8This was very good! I was really happy when the first code on the page, for once, did not look like it was written by someone writing C when they would much rather write something else. This line: struct article *my_article = malloc(sizeof *my_article); Is almost exactly how I would have written it, and (to me) does three things very right: - Does not use a pointless, wordy, bloated cast to somehow "convert" the poin…
For context, the reason why you often see explicit casts from void* to other pointer types is that C++ forbids implicit casts from void*, which is one of the few compatibility breaks that C++ did with C.
(For better or for worse, people often compile C-style code with a C++ compiler)
Re: Visual overview of a custom malloc() implementation
#9Why are the letters ’p’, ’q’ and ’t’ missing from the article? Makes it a bit annoying to read.
I also had that issue when reading the article on Safari/iOS. Switching to reader mode fixed it though.
No issue on Firefox/Linux.
Looks like a platform-specific font rendering issue?
Re: Visual overview of a custom malloc() implementation
#10Unfortunately the author is violating POSIX here by defining his own _t types, which is a suffix reserved for the system. Too bad since everyone likes it.
If you're writing your own malloc(), you could argue you are legitimately part of the system implementation. Those type names are reserved for you.