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

Cosmopolitan Libc: build-once run-anywhere C library

justine.lol

Post reply on HN
Print view View original

21–30 of 171 posts

Re: Cosmopolitan Libc: build-once run-anywhere C library

#21

Post by kjiuui774 »

jart wrote: post #18
jws wrote: post #12

Doesn’t the “strlcpy” example near the bottom of the page overwrite the buffer by one byte when the source string is as long or longer than the buffer? Imagine I have a three byte buffer, n is 3 and I copy in “foo”. The result of the MIN is going to be three. And d[3] is the fourth byte of my three byte buffer.

Author here. The example and repository has been updated. Many eyes make all bugs shallow. I was hoping to do more testing before posting on Hacker News. Now that the cat's out of the bag, I'd like to explain what's being done to make sure bugs like that never happen. Cosmopolitan implements a simplified version of the Address Sanitizer (ASAN) runtime. See https://github.com/jart/cosmopolitan/blob/master/libc/log/as.…

Have you ever tried C formal verification tools? Check out open source Frama-C https://frama-c.com which uses ACSL (ANSI/ISO C Specification Language). The free documentation and tutorials are pretty good.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#22

Post by moonchild »

jart wrote: post #11
qlk1123 wrote: post #4

Sorry for being naive, but how can it be possible that nobody had thought of this approach and this approach would have actually worked? What have been preventing people from coming up with something like this?

Author here. Here's the best explanation I've thought of so far: > If it's this easy, why has no one done this before? The best answer I can tell is it requires an minor ABI change, where C preprocessor macros relating to system interfaces need to be symbolic. This is barely an issue, except in cases like switch(errno){case EINVAL:...}. https://justine.lol/ape.html It also took an act of willpower. This is a novel ap…

Why not keep constants constant (so your switch example works), but have an extra translation step in front of the syscalls?

Re: Cosmopolitan Libc: build-once run-anywhere C library

#23

Post by groodt »

This is very clever. I wonder if it could be adopted for Python C extensions (where possible) to make it easier to distribute cross-platform binary distributions. Of course it wouldn’t be suitable for gui toolkits, but I imagine that the majority of Python C-extensions could be handled.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#24

Post by shakna »

modeless wrote: post #13
mmastrac wrote: post #3

It appears to build a "naked" thompson shell script without a shebang line that works as a PE file for Windows/DOS, and uses `exec` to feed a binary to the shell via a pipe. Interesting approach for a universal binary.

A downside of this approach is the binary can't be executed with the exec system call because the kernel doesn't recognize scripts without a shebang. It can only be executed from within a shell.

> A downside of this approach is the binary can't be executed with the exec system call because the kernel doesn't recognize scripts without a shebang. It can only be executed from within a shell.

It's a little bit more nuanced than that, depending on the platform. You don't necessarily need to have a shebang. This behaviour is guaranteed in Linux, and traditional on BSD, but not POSIX:

> If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)

Which means that it _should_ work outside a shell on those systems.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#25

Post by BeeOnRope »

This approach of using inline asm wrappers around functions which specify exactly the clobbered registers is neat, but...

I don't think the approach of making a call from inline asm is safe. In particular, it clobbers the redzone [1], which the compiler may have used and expect to be intact after the call.

In general, at least some compilers (e.g., gcc) assume there are no calls in an inline asm block.

---

[1] https://godbolt.org/z/e4ecKr

Re: Cosmopolitan Libc: build-once run-anywhere C library

#27

Post by smcameron »

> Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets [...]

Not to diminish the achievement at all, but a significant limitation to be noted (and not a very surprising limitation).

I also wonder about things like the sizeof(long). On 64-bit linux, this is 8, but on windows, it's 4. Well, "on windows"... maybe this throws all the APIs that make such assumptions, uh, out the window, (puts on sunglasses).

Re: Cosmopolitan Libc: build-once run-anywhere C library

#28

Post by jart »

BeeOnRope wrote: post #25

This approach of using inline asm wrappers around functions which specify exactly the clobbered registers is neat, but... I don't think the approach of making a call from inline asm is safe. In particular, it clobbers the redzone [1], which the compiler may have used and expect to be intact after the call. In general, at least some compilers (e.g., gcc) assume there are no calls in an inline asm block. --- [1] https:…

Cosmopolitan doesn't use the "red zone" because these binaries boot on bare metal and operating system code can't assume a red zone. GCC supports this. Otherwise the Linux Kernel wouldn't work, since it's compiled the same way. So invoking call from inline asm is perfectly safe. The only real issue is that the called function can't assume the stack is 16-byte aligned. But that's fine, since Cosmo only using asm(call) to call functions written in assembly.

Re: Cosmopolitan Libc: build-once run-anywhere C library

#29

Post by qlk1123 »

jart wrote: post #11
qlk1123 wrote: post #4

Sorry for being naive, but how can it be possible that nobody had thought of this approach and this approach would have actually worked? What have been preventing people from coming up with something like this?

Author here. Here's the best explanation I've thought of so far: > If it's this easy, why has no one done this before? The best answer I can tell is it requires an minor ABI change, where C preprocessor macros relating to system interfaces need to be symbolic. This is barely an issue, except in cases like switch(errno){case EINVAL:...}. https://justine.lol/ape.html It also took an act of willpower. This is a novel ap…

Fair enough and inspiring. However I am still wondering how to advocate changes in such a scale.

For example, Linux introduces some fixes for Y2038 problem during the past few years. I suppose the community of this C library should do something for those changes, right?

Post reply on HN