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

91–100 of 171 posts

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

#91

Post by jart »

saagarjha wrote: post #79
vitiral wrote: post #2

I'm a huge fan of the ideas behind this library. Using the stable ABI of "magic numbers" is brilliant. Would love to see this solution gain more usage!

Sadly, the "magic numbers" are much less stable than you'd think.

That's like saying the '9' in kill -9 might change someday. However it really does depend on which numbers. In the APE blog post I mention the importance on focusing on the subset of numbers that systems share in common. In other words, the really old ones. https://github.com/jart/cosmopolitan/blob/master/libc/sysv/c...

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

#92

Post by andi999 »

pwdisswordfish5 wrote: post #73
andi999 wrote: post #62

Can somebody explain the whole thing to me? I know how to programm on windows and linux, but thats basically at the level of calling the compiler and linker, and some parameters to sometimes build a dll. So what does this do, and how does it work? Does it apply to DLLs as well? Also, 'run anywhere' means on the same processor type?

It’s a libc implementation accompanied by a linker script that tricks the linker into generating a polyglot executable file, simultaneously interpretable as an MZ executable, x86 boot sector and a Unix shell script, the latter of which re-writes the executable into ELF or Mach-O format and then executes it again. I haven’t analysed it all that thoroughly, but that’s the gist of it. Here’s more information: https://ju…

How is the libc polyglot? I mean don't system call vary widely between windows and Linux?

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

#93

Post by Santosh83 »

rhdxmr wrote: post #45

Wow I am very surprised that this could happen. An executable that can run on every platform? I am curious about it

When you think about it, 99% of the code of a compiled C program is processor specific object code which in theory should not care about the operating system or environment at all. It is the 1% like API/ABI and header magic that makes the same object code incompatible under different OSes.

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

#95

Post by pwdisswordfish5 »

andi999 wrote: post #92
pwdisswordfish5 wrote: post #73

Earlier quoted context omitted.

It’s a libc implementation accompanied by a linker script that tricks the linker into generating a polyglot executable file, simultaneously interpretable as an MZ executable, x86 boot sector and a Unix shell script, the latter of which re-writes the executable into ELF or Mach-O format and then executes it again. I haven’t analysed it all that thoroughly, but that’s the gist of it. Here’s more information: https://ju…

How is the libc polyglot? I mean don't system call vary widely between windows and Linux?

    int ftruncate(int fd, int64_t length) {
      if (!IsWindows()) {
        return ftruncate$sysv(fd, length);
      } else {
        return ftruncate$nt(fd, length);
      }
    }
You get the idea. The OS is detected at startup and then checked each time a function is invoked.

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

#97

Post by fwsgonzo »

This is what I've been working on with RISC-V, and you have no idea how much resistance I get when I try to fix the problems relating to calling conventions, inline assembly and system calls.

I don't want to have to explain what I'm doing from the beginning every time I have a complex question about how to make a function call from inline assembly. It has really turned me off from stackoverflow as a whole. Sorry for the rant.

I think your project is awesome, and really shows that we can improve the base upon which everything rests.

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

#99

Post by ben_bai »

harikb wrote: post #15
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.

I think you are right. `strlcpy` is only supposed to copy `n-1` bytes from src to dest. https://github.com/freebsd/freebsd/blob/master/sys/libkern/s...

strlcpy always NUL terminates the string (that is it's big selling point). So it copies up to n-1 bytes from src to destination. If src was bigger then destination it is truncated and n-th byte is set to NUL.

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

#100

Post by MaxBarraclough »

jart wrote: post #34
TimTheTinker wrote: post #32

This is an interesting, and potentially compelling argument that WebAssembly binaries and runtime actually aren’t the future of compile-once-run-anywhere systems software: these support syscalls, sockets, and stdin/stdout —- all of which requires platform-specific glue code to achieve using WebAssembly and standard libc (or JS).

Author here. WebAssembly has played an important role protecting CI on the Internet and it's cool that it enables us to run LLVM in the browser. I was very surprised when I learned that some people were using it offline outside of browsers, since doing so requires a JVM-like runtime such as wasmtime. Cosmopolitan proves that it's possible to just fix C instead, which might fix all the stuff that's built on top of C t…

> doing so requires a JVM-like runtime such as wasmtime. Cosmopolitan proves that it's possible to just fix C instead

This doesn't sound like a fair comparison. WASM isn't just providing portability, it's also providing security and runtime safety. Cosmopolitan doesn't, it presumably requires you to trust the codebase, and doesn't protect you from C's undefined behaviour. Of course, WASM also imposes a considerable performance penalty, I presume the Cosmopolitan approach easily outperforms WASM.

> This is probably how Java would have been designed, if Intel's instruction set hadn't been encumbered by patents at the time.

To mirror the comment by Someone, I sincerely doubt this. Java bytecode is a very high level stack-based IR, nothing like a CPU ISA. They could easily have made it resemble a CPU ISA if they'd wanted to. The lesser-known GNU Lightning JIT engine takes this approach, for instance.

Post reply on HN