Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing C software without the standard library

weeb.ddns.net

Post reply on HN
Print view View original

81–90 of 188 posts

Re: Writing C software without the standard library

#81

Post by SonOfLilit »

bonzini wrote: post #41
SonOfLilit wrote: post #27

Earlier quoted context omitted.

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.

I tip my hat to you, your analysis is far more interesting than mine.

Re: Writing C software without the standard library

#82

Post by makapuf »

masklinn wrote: post #67
makapuf wrote: post #47

Earlier quoted context omitted.

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

> A .h file with different syscalls IDs That's not portable even across versions of the same OS, many OS don't support raw syscalls and don't make any guarantees about them. That's why you can't statically link libc on OSX for instance, libSystem is literally the system's interface and necessarily dynamically linked.

That would be the few inline functions so to abstract a bit the syscalls.

Re: Writing C software without the standard library

#83

Post by IshKebab »

badsectoracula wrote: post #19
dvfjsdhgfv wrote: post #14

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…

> wasting resources

I don't consider variable-width fonts, nice margins and dynamic word wrapping to be a waste of resources.

There's a sane middle ground between Electron and the 70s.

Re: Writing C software without the standard library

#84

Post by masklinn »

userbinator wrote: post #80

A value in the range between -4095 and -1 indicates an error, it is -errno. The syscall/errno stuff has always seemed unusual, inelegant, and inefficient --- instead of just returning a negative error code directly, the function returns the vague "an error has occurred" -1, and you have to then check errno separately after that. It only adds insult to injury when you realise that the kernel itself isn't doing it, but…

> At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years

IIRC raw syscalls are an officially supported kernel API, that's why you can have alternate libc implementations (e.g. musl), and Linux is an oddity in that, on most systems even if the syscalls are fairly stable there are no actual guarantees with respect to them, and the only officially supported interface to the kernel is the standard library. OSX does not allow statically linking libSystem for that reason for instance.

Re: Writing C software without the standard library

#85

Post by imron »

userbinator wrote: post #78
imron wrote: post #74

Earlier quoted context omitted.

I've written Windows programs without the std library. The Win32 has plenty of replacement functions you can use instead though so it's much less work than what's presented here. You get the same sorts of benefits though.

Win32 is itself a layer on top of the syscalls, and already provides much of the functionality of the C standard library.

Yes, that was partly my point.

You can get reduced executable size and a lack of dependencies on various msvc*.dlls, without giving up much of the functionality of the C standard library and without having to write it all yourself.

Re: Writing C software without the standard library

#86

Post by DSMan195276 »

pawadu wrote: post #38

I think this is unnecessary when you got : typedef unsigned long int u64; typedef unsigned int u32; ... if you define your own types like this you may need to revise them when you switch architecture or even compiler. Now you could argue that this is part of the standard library, but I actually see it as a part of the standard C language.

You're getting down-voted (Which is unnecessary IMO) but you're really not wrong. `gcc` itself provides `stdint.h`, it's not actually part of libc - or rather, you can use it without actually having a libc in place. Generally this is a good move, because you can always write a `stdint.h` replacement on arch's that don't have one, but on ones that do you're guaranteed to get the types correct.

Re: Writing C software without the standard library

#87

Post by masklinn »

makapuf wrote: post #82
masklinn wrote: post #67

Earlier quoted context omitted.

> A .h file with different syscalls IDs That's not portable even across versions of the same OS, many OS don't support raw syscalls and don't make any guarantees about them. That's why you can't statically link libc on OSX for instance, libSystem is literally the system's interface and necessarily dynamically linked.

That would be the few inline functions so to abstract a bit the syscalls.

It doesn't abstract anything, if the syscall changes your "abstract a bit" will be broken all the same. On many if not most OS the machine code side of the syscalls can change with no notice, Windows has changed syscalls in minor revisions, Go broke several times during the Sierra beta due to syscall changes (because it handrolls gettimeofday(2) whose assembly calling convention changed).

The proper abstract interface on non-linux systems is the standard library.

Re: Writing C software without the standard library

#88

Post by pjc50 »

capnfantasic wrote: post #2

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

malloc() isn't particularly hard; K&R provides a working implementation using a freelist and sbrk in about a page of code. It's printf() that's the horrendous feature-crammed nightmare.

Re: Writing C software without the standard library

#89

Post by nuclx »

pg314 wrote: post #50
majewsky wrote: post #44

Earlier quoted context omitted.

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…

FreeRTOS also provides a few malloc implementations backed by static arrays (not dependent on sbrk), which can be useful for running malloc-based test code on embedded platforms without native malloc: http://www.freertos.org/a00111.html

Re: Writing C software without the standard library

#90

Post by WhiteHat1 »

Very interesting. How much of a pain is this? Definitely worth looking.

Of course there are other solutions to the problems as well. You can speed up linking by using IncrediBuild.

But the last reasons (fun challenge!) and understanding the inner workings are useful, especially for software engineers.

Post reply on HN