Live data from Hacker News

Writing C software without the standard library

weeb.ddns.net

41–50 of 188 posts

Re: Writing C software without the standard library

#41

Earlier quoted context omitted.

Traditionally yes. On the latest CPUs - who knows.

Probably yes, because Intel knows this is the code every compiler outputs for zeroing a register. Also, the reason it is "faster" is that the encoding is 1 byte, vs. 9 bytes (in 64 bit) for "mov rbp, 0" - roughly, 1 for "mov rbp,", 8 more for a 64 bit "0".

Technically you could get by with 5 bytes for "mov ebp, 0".

Another reason why it was faster was that the processor recognized it and avoided partial flags stalls after an "inc". But in 64-bit code you rarely have "inc" at all, so it matters less. On the other hand, a few years ago XOR had a false dependency on the register you're clearing; I'm not sure it is still that way on more recent processors.

Re: Writing C software without the standard library

#42
post #39
post #31

Earlier quoted context omitted.

Portability is impossible without the standard library.

What ? You just write your OS layer for each platform and it's portable.

True. The OS layer you write (and port to other OSes) is called "the standard library". :-)

Re: Writing C software without the standard library

#43

The comment section where gcc puts in ident info can be omitted with -fno-ident and syscall(2) is usually a very thin wrapper[0]. If you follow the musl syscall(2) it simply maps errors to errno[1] and uses the fancy count-args-in-macro[2] to call off the respective $arch/syscall_arch.h[3] syscall$n numbered functions. [0] https://git.musl-libc.org/cgit/musl/tree/src/misc/syscall.c [1] https://git.musl-libc.org/cgit/…

Highly recommend reading the Musl source code if you want to find out how things work. Don't bother trying to look at Glibc.

Re: Writing C software without the standard library

#44
post #17

Fantastic until you need to malloc. You're reimplementing libc, but at least you know what's going on at every level.

You can get surprisingly far without using libc's malloc/free. E.g. TeX, the typesetting system by Knuth, implements its own dynamic memory handling. It has a large static array of bytes, and allocates from that when needed.

That's an arena allocator: https://en.wikipedia.org/wiki/Region-based_memory_management

Arenas are really nice if you're allocating a lot of objects of the same size, whereas malloc() must be prepared to handle a lot of different memory usage patterns.

Re: Writing C software without the standard library

#45

Earlier quoted context omitted.

Unless you also need to free, it's pretty simple.

Of course. When I wrote that comment I asked myself should I have written "malloc" or "malloc/free" - surely one implies the other.

Oh well, with 16 GB RAM even in laptops, who needs free anymore? Just restart the program. It's simpler anyway.

Re: Writing C software without the standard library

#46

The guy is definitely a fan of old-school minimalism: http://weeb.ddns.net/0/articles/modern_software_is_at_its_wo... I have to say I miss the old days of Gopher, too. It was so much easier to focus on the content back then.

I find myself agreeing with him 100%. Not just on Gopher (although i did write a Gopher client some time ago - http://runtimeterror.com/tools/gopher/ ) but on the entire rant about wasting resources, UIs that waste screen real estate and become unusable in smaller resolutions, fonts that only look good with anti-aliasing and have weird misplaced pixels with antialiased disabled (which i also do), websites that make r…

  > I've even seen functionality regression for the sake of modern and
  > "responsive" design in many cases.
  >
  > For example, you used to be able to browse youtube favorites in
  > pages. Whoops, not anymore! Now you need to scroll down and
  > painfully wait for the site to make its stupid animation and load
  > the next page.
  > What's worse is, you can't just skip through pages. You have to
  > load EVERYTHING and it all stays loaded, so after 10-20 pages the
  > browser starts to lag and hog cpu just to scroll.
I see this issue more and more, scrolling is broken in so many sites, even popular ones like FB. Plus, often search doesn't look in the "scrollable" content, i.e. you need to load (=scroll) all these "pages" and rely on the browser search function. Many small things like this, e.g. snippets of code that don't fit the DIV box and you need to scroll horizontally. And news pages lagging on a i7 w/ 16Gb or RAM. It's all so sad.

Re: Writing C software without the standard library

#47
post #42
post #39

Earlier quoted context omitted.

What ? You just write your OS layer for each platform and it's portable.

True. The OS layer you write (and port to other OSes) is called "the standard library". :-)

A .h file with different syscalls IDs and perhaps a few inline functions is hardly a standard library though

Re: Writing C software without the standard library

#48
post #32
post #4

He claims that your code will be easy to port but then goes straight to Linux system calls. Still I like the idea. This is something that should be covered in a CS 102 type course. I know way to many cs guys who have no idea how to debug, let alone how their is being implemented.

> He claims that your code will be easy to port but then goes straight to Linux system calls. These are nowadays supported by Windows and few BSDs too, who needs more portability than that :)

"Supported on Windows" is a strong claim. They are supported in the Linux subsystem, but asking your users to install that seems far fetched to me.

Re: Writing C software without the standard library

#49
post #45

Earlier quoted context omitted.

Of course. When I wrote that comment I asked myself should I have written "malloc" or "malloc/free" - surely one implies the other.

Oh well, with 16 GB RAM even in laptops, who needs free anymore? Just restart the program. It's simpler anyway.

ironic for a minimalist/anti bloat pamphlet to start with "with 16GB ..."

Re: Writing C software without the standard library

#50
post #17

Earlier quoted context omitted.

You can get surprisingly far without using libc's malloc/free. E.g. TeX, the typesetting system by Knuth, implements its own dynamic memory handling. It has a large static array of bytes, and allocates from that when needed.

That's an arena allocator: https://en.wikipedia.org/wiki/Region-based_memory_management Arenas are really nice if you're allocating a lot of objects of the same size, whereas malloc() must be prepared to handle a lot of different memory usage patterns.

I don't think it is. Differently sized objects can be allocated and released individually. Have a look at part 9 of [1]. In an arena based allocator you typically deallocate all the objects in an arena at once.

TeX basically uses a special purpose implementation of malloc/free, with a static array as backing instead of memory requested from the OS with mmap(2) or sbrk(2). The main reason is portability (the original version was released in 1978 using WEB/Pascal).

[1] http://brokestream.com/tex.pdf

Post reply on HN