It's posts like this (and the accompanying comments) that make me realize how much I still have left to learn!
One of the reasons that I love HN is how informative you all are!
Writing C software without the standard library
131–140 of 188 posts
Re: Writing C software without the standard library
#132Earlier 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.
For short-lived processes that do lots of allocations and where you can rely on the OS to release resources, just leaving out the deallocations is often faster.
Of course, you need to be careful as if you write code like that in a language without garbage collection, it's inherently not reuseable - retrofitting deallocation is often really painful because it gets easy to adopt patterns that make object ownership etc. unclear when you don't have to ensure it's easy to deallocate in the right order.
Re: Writing C software without the standard library
#133A 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 persona…
So a few things to consider in regards to point 1:
* Your executable is going to be loaded as a whole page regardless of how large it is, on most platforms this means you'll need at least 4k of User VM.
* You'll need a page table, which has its own overhead. If someone was going to push back on the libc assertion I'd expect it here, a the PTEs for libc and and the VDSOs cannot be shared between processes (as far as I'm aware).
* I would expect it to in theory RUN faster assuming it was a small toy program like the example, this is because there is less work to be done even with shared pages.
Re: Writing C software without the standard library
#134The server is getting hit pretty hard right now, did not expect this much traffic. In the meantime, you can find a bbcode mirror of the guide here: https://ccplz.net/threads/writing-c-software-without-the-sta...
Re: Writing C software without the standard library
#135A 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.…
He spoke about the space savings of the binary itself (which must be debug things and statically linked code). There is no sharing of that , unless multiple processes run that same binary.
Re: Writing C software without the standard library
#136A 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.…
Can you elaborate on why this "will prevent the use of VDSOs"?
Why can't I just call gettimeofday() which will access the vdso page mapped into my address space?
Re: Writing C software without the standard library
#137Earlier 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.
Indie games do this too. My favorite examples are:
Hatoful Boyfriend (remake that uses Unity), a simple graphical choose your own adventure with no animation at all that is painfully slow on my 3-4 year old laptop (although this must be intentional for some reason, it is hard to imagine how that could be achieved purly by abuse of unity)
Lethis - Path of Prgress a 'hipster retro' sim city in a steam punk world that fails to work at all with Intel integrated graphics.
Re: Writing C software without the standard library
#138It's a very good learning process. But once your project scales up, you are essentially writing your own libc.
And there is no portability. It only works with the specific architecture's calling convention and the specific c compiler.
Re: Writing C software without the standard library
#139I can't believe this post has 409 points. Are we in the 80's again ?
Re: Writing C software without the standard library
#140I 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.
I use stdint.h too, but I'm honestly curious if there is any common platform around today where one of the following asserts fails:
int main() {
assert(sizeof(signed char) == 1);
assert(sizeof(short) == 2);
assert(sizeof(int) == 4);
assert(sizeof(long long) == 8);
return 0;
}
And for what it's worth, using typedefs based on the above provides more readable printf strings. This is hideous:
int main() {
int64_t portable = 123;
printf("Ugly: %" PRId64 "\n", portable);
return 0;
}
int main() {
long long palatable = 123;
printf("Better: %lld\n", palatable);
return 0;
}