Live data from Hacker News

Writing C software without the standard library

weeb.ddns.net

121–130 of 188 posts

Re: Writing C software without the standard library

#121
post #113

Earlier quoted context omitted.

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…

> The only bit i'd disagree would be with games, at least on AAA games since i have some experience there and -at least at the engine level- there is still a lot of low level wizardry being done there. He explicitly calls out people "writing poorly performing code on top of pre-made engines". I'm pretty sure he's aiming most of his ire at non-indies using Unity3D or Unreal.

Personally, I don't mind this at all, mostly because they wouldn't be writing anything if it weren't for Unity and Unreal.

Re: Writing C software without the standard library

#122
post #3

> Executables are incredibly small (the http mirror server for my gopherspace is powered by a 10kb executable). Is this ever an real issue, even on any embedded system in the last 20 years?

Yes, executable size is still a modern day problem. Imagine you're shipping an OS; do you want the hundreds of thousands of executables in your system to all be a few percentage larger when you're trying to ship to a customer who may only have 16 or 32 GB of storage space?

Of course, removing libc won't be your first (or second or third or ...) step for removing bloat from a mature codebase.

Re: Writing C software without the standard library

#123
A few thoughts:

* The space savings are moot as other processes such as the daemons are going to load libc into virtual memory anyway, and the kernel shares libc's page among all processes.

* This adds a lot of LOC you have to maintain, instead of shoving it off on the compiler/libc vendor, this increases the chance of bugs.

* This will prevent the use of VDSOs to optimize high volume system calls like gettimeofday.

* It's still probably good to know how these happen, even if you're not doing them yourself.

* The only place this would really see benefit is in a single process environment, however in those cases I would suggest a unikernel anyway for simplicity sake.

Re: Writing C software without the standard library

#124
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.

Suppose you want to port to some architecture not supported by libc. If you were using libc you would have to find a replacement that works and targets that arch or port libc yourself. If you wrote everything from scratch, instead, you just have to read the specification and add support to your code. That's what I meant.

Of course, if your target archs are all supported by libc, porting is much easier with libc.

Re: Writing C software without the standard library

#125
post #106

Earlier quoted context omitted.

golang also targets syscalls instead of the C standard library (or other libraries except for windows, and maybe others), which is interesting on e.g., Darwin: https://github.com/golang/go/issues/17490

Yeah the linked issue (16570) is the most interesting one, with the Go runtime breaking multiple times in the runup to Sierra as Apple changed the ABI of the underlying gettimeofday syscall.

Wow, that seems like a really bad approach for Go to take. So is anybody actually using Go on OS X? I guess maybe not, if all the real Go deployments are on servers running Linux.

Re: Writing C software without the standard library

#126

Earlier quoted context omitted.

Yeah the linked issue (16570) is the most interesting one, with the Go runtime breaking multiple times in the runup to Sierra as Apple changed the ABI of the underlying gettimeofday syscall.

Wow, that seems like a really bad approach for Go to take. So is anybody actually using Go on OS X? I guess maybe not, if all the real Go deployments are on servers running Linux.

I do a bunch of development work using Go on OSX but I do deploy the resulting solutions on Linux.

Re: Writing C software without the standard library

#127
post #123

A few thoughts: * The space savings are moot as other processes such as the daemons are going to load libc into virtual memory anyway, and the kernel shares libc's page among all processes. * This adds a lot of LOC you have to maintain, instead of shoving it off on the compiler/libc vendor, this increases the chance of bugs. * This will prevent the use of VDSOs to optimize high volume system calls like gettimeofday.…

I'd be interested to see benchmarks to consider point one. At face value, I fully agree with your point and doubt it has any benefit. However, it is less that has to be swapped in for your program to run. Would be curious if this has an odd cache friendliness for an application.

The tooling answer to this, it seems, would be to support statically linked libraries. But again, I would want to see numbers before personally worrying about this.

Re: Writing C software without the standard library

#130

I had a question about this sentence: "It's often necessary to either push useless data or simply align the stack pointer when the pushed values don't happen to be aligned." That's kind of hand-wavy. How do we "simply align the stack pointer"?

On most architectures, by decrementing it appropriately. E.g. subtract 4 to align from a 4-byte to an 8-byte boundary.

Thanks for the responses.
Post reply on HN