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

171–180 of 188 posts

Re: Writing C software without the standard library

#171

Post by bogomipz »

bodyfour wrote: post #156
77pt77 wrote: post #151

Earlier quoted context omitted.

> The syscall/errno stuff has always seemed unusual, inelegant, and inefficient And non-reentrant. errno is usually defined as TLS (thread local storage). It's a mess.

Yes, if UNIX had supported multithreading from the start, there is no way they would have chosen "errno" as the solution. Obvious in hindsight, not so much in the 1970s.

Can you elaborate on how "errno"'s design is rooted in the fact that there was no multithreading at the time? I am not understanding the connection. Thanks.

Re: Writing C software without the standard library

#172

Post by bogomipz »

lolisamurai wrote: post #124
vxNsr wrote: 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.

What are some archs that arent't supported by libc? Just embedded systems?

Re: Writing C software without the standard library

#173

Post by bogomipz »

sebcat wrote: post #106
masklinn wrote: post #84

Earlier quoted context omitted.

> 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 s…

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

>"golang also targets syscalls instead of the C standard library"

What would have been the reasons for targeting syscalls directly instead of the C standard library?

Re: Writing C software without the standard library

#174

Post by int_19h »

goldfire wrote: post #143
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…

> Unfortunately the Windows syscalls are not officially documented and even less stable than on Linux, changing even between service packs. You can get pretty close though; it's possible to skip the C runtime and most of the other user space libraries and call into ntdll directly. Many of the functions it exports are fairly thin wrappers over the system calls.

ntdll.dll is still not a stable API - if you use anything exported from it (excepting a few documented ones), you basically have zero guarantee that your app will still be working with the next Windows update.

Re: Writing C software without the standard library

#175

Post by Ace17 »

77pt77 wrote: post #151
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…

> The syscall/errno stuff has always seemed unusual, inelegant, and inefficient And non-reentrant. errno is usually defined as TLS (thread local storage). It's a mess.

Is TLS actually needed for anything else than errno/GetLastError/SDL_GetError/etc. ?

Re: Writing C software without the standard library

#176

Post by aduffy »

bogomipz wrote: post #173
sebcat wrote: 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

>"golang also targets syscalls instead of the C standard library" What would have been the reasons for targeting syscalls directly instead of the C standard library?

I'm guessing it has to do with the fact that you can build go binaries not linked with libc, they also expose syscall.RawSyscall anyway that all the other syscall wrappers call out to last time I looked

Re: Writing C software without the standard library

#177

Post by bonzini »

SonOfLilit wrote: post #81
bonzini wrote: post #41

Earlier quoted context omitted.

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.

Wrong too, it's partial register stalls not partial flags stalls.

Re: Writing C software without the standard library

#178

Post by masklinn »

bogomipz wrote: post #173
sebcat wrote: 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

>"golang also targets syscalls instead of the C standard library" What would have been the reasons for targeting syscalls directly instead of the C standard library?

> What would have been the reasons for targeting syscalls directly instead of the C standard library?

Since the standard library probably assumes (and requires) a C stack, linking against the standard library would require cgo (or some other specific workaround) on non-linux platforms.

Re: Writing C software without the standard library

#179

Post by IshKebab »

lj3 wrote: post #114
IshKebab wrote: post #83

Earlier quoted context omitted.

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

That ground is mostly unexplored. IMHO, the sane middle ground between Electron and the 70s isn't shoving an entire browser inside a desktop app. It's using modern programming and compiler techniques to get close to the metal without having to deal with all of the shortcomings of C/C++. It's also using UI libraries that make creating desktop UIs as easy as making a website, but with better performance. Sadly, neither…

I agree. Something like QML is sort-of what we need, but that is still too closely tied to C++ and not mature enough.

I'm hopeful about Go GUIs though. Go is an easy language to use and performant enough for complex GUI apps. Google abandoned gxui but it seems like they are backing Shiny at least a little.

Re: Writing C software without the standard library

#180

Post by lomnakkus »

bogomipz wrote: post #171
bodyfour wrote: post #156

Earlier quoted context omitted.

Yes, if UNIX had supported multithreading from the start, there is no way they would have chosen "errno" as the solution. Obvious in hindsight, not so much in the 1970s.

Can you elaborate on how "errno"'s design is rooted in the fact that there was no multithreading at the time? I am not understanding the connection. Thanks.

Multithreading usually means that threads share the address space and so can (inadvertently) stomp on each other's "errno". (Hence making it Thread-Local Storage to solve that issue. Doesn't solve the reentrancy issue, though.)

If multithreading were pervasive nobody in their right mind would choose to use a global variable for error status codes.

Post reply on HN