My new distro "Glacies" - GNU/Linux
(10-12-2019, 08:48 PM)josuah Wrote: Hello, Dan Berstein-style libc, happy to see you around! scanf()? No thank you!
I have never seen Dan Bernstein-style code crafting an Operating System, and I am eager to look at it.
Actually, i am a heretic to his ways, i am making use of a string formatted routine to output, although don't plan to provide a similar one to input (skalibs is one similar lib that follows more strictly djb style, although relies on the standard libc)

(10-12-2019, 08:52 PM)josuah Wrote: If you do not mind, would you happen to have a few tips for where to get started?
OSDev is a pretty good place to gather information about how to start, and is very likely to be the better one, because it has plenty information for each step, and citates a lot of others helpful sources. Following a implementation process of a simple system may be the better way to get the grasps of how things works, allowing you to experiment further (the OSDev has a "OS Implementations" section in its books page)

(10-12-2019, 08:52 PM)josuah Wrote: ? XV6 ? Linux kernel source ? All of em ?
Reading "real" operating systems code may show itself to be of little productivity, because you will get too much details (linux code is mostly drivers), and i think that is better to understand what must be done in its most basilar form, only then those details start to have value; so smaller systems are better in this regard, for example: the already cited xv6 (this one is good, small and has a book), temple os (simpler design, all ring 0), minix (has andrew books addressing it), etc.
Update: Did a little more detailed description of the project[0], with a few examples and videos (qemu+ncurses recorded with asciinema), of the project. Later i will make a more detailed post about Glacies itself, and then a few benchmarks and comparisons of the tools with others of similar purpose (coreutils, libc, package manager, etc.).
I like the hierarchical naming.

C somehow lacks namespaces, but the '_' char does it well!

It is an idiom well-adopted by the community for library namespaces, so that the integrate well with the end project.

Some project end up using namespaces for splitting different sections of their library.

If you combine the two (let's say, it is a general purpose programing library with multiple sections), you get a 2-fold library namespace.
Stralloc from DJB :
Advised: reading malloc(3) and realloc(3) man page and the link above. That's it...

The libstralloc is a very tiny (~60 lines?) library to build strings onto a simple struct with a pointer to a malloc()ed buffer (->s) the available size of that buffer (->a), and the used size (->n).

You end up using stralloc_cats(sa, "text") without extra checking for "is there enough room in the string sa?":
if there is not enough room, stralloc_cats will realloc sa->s and denote thew available size in sa->a.

Why having both ->a and ->n ? Because while adding more memory, stralloc_cats() will do a little planning and ask for more than just the new length of the string to build, so that it does not have to call realloc too often...

BUT, this, the libc already does it! :)

Check by reallocating a string and printing its address:

#include <stdio.h>
#include <stdlib.h>
int main(void) {
char *p = NULL;
printf("%p\n", p = realloc(p, 10));
printf("%p\n", p = realloc(p, 11));
printf("%p\n", p = realloc(p, 13));
printf("%p\n", p = realloc(p, 20));
return 0;

Only the 1st and the 4th call to realloc did actually copied the old buffer to a new, larger one.

My very humble benchmark did show that, on some example of malloc I used,:

- using strlen() to add bytes by bytes was much slower than using stralloc (so keeping the size ->n is a really good idea, which most programming languages does),

- keeping track of the usable size (->a) of the buffer adds very little advantage over using realloc every time a string is added

Why the second point? Note that malloc()/realloc() is not a syscall!

Most malloc implementations (if not all), have a block describing the buffer just before it, so the "usable buffer size" is already saved, somewhere *before* the ->s pointer, and it very fast for realloc() to pick it up :

Possible memory layout:
-- ,---- S (char *, struct stralloc)
-- | --- A (size_t, struct stralloc)
-- | --- N (size_t, struct stralloc)
-- | ---
-- | --- [...]
-- | ---
-- | ---
-- | --- [...]
-- | --- (??? memory used by malloc)
-- | --- (??? memory used by malloc)
-- `> - s[0] (char, malloc()ed buffer)
-------- s[1] (char)
-------- s[2] (char)
-------- s[3] (char)
-------- [...]

Somewhere in "??? memory used by malloc" (imlementation-specific), there is the capacity of the buffer stored, for internal use by malloc/realloc (which precisely know where to look).

So I got rid of of the ->a field (capacity) in the stralloc library, to only have ->s (sring pointer) and ->n (total length) left.

Beside than that (which mean I had to go over-pedantic), I rarely found a way to do more concise than DJB's libc and be confident that I was not breaking something elsewhere doing so.

Programming with DJB's libraries makes you an alien. A minimalist, efficient, safe and correct alien.
(13-01-2020, 08:42 PM)josuah Wrote: I like the hierarchical naming.
It was chosen to avoid name collision (one of the standard libc "sins") and to organize related sections.

(13-01-2020, 09:12 PM)josuah Wrote: - keeping track of the usable size (->a) of the buffer adds very little advantage over using realloc every time a string is added
I disagree, because calling realloc with just the required space is not optimal, and it will shrink the buffer unnecessarily if reused (while not being possible to shrink when necessary). That said, if you intend to use only short strings, those problems are pretty much irrelevant.

(13-01-2020, 09:12 PM)josuah Wrote: Programming with DJB's libraries makes you an alien. A minimalist, efficient, safe and correct alien.
True. Usually all his code have a good design, and most of the people that followed his ways are writing code with similar quality (see:

Members  |  Stats  |  Night Mode