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

151–160 of 171 posts

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

#151

Post by ssokolow »

roca wrote: post #87
jart wrote: post #34

Earlier quoted context omitted.

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…

"Only require JIT compilation if they're launched on a non-x86 machine" is a heck of a caveat. The x86-64 instruction set is not a good portable IR. Some well-known problems: * It's much more irregular to decode than other instruction sets/IRs * There is a truly vast set of instructions, very many of which are almost never used. So in practice you need to define the subset of x86-64 you're using. E.g. does your subse…

> * It's much more irregular to decode than other instruction sets/IRs

According to this blog post, it's not just "much more irregular to decode", instruction deciding is the Achilles Heel of x86 which allows M1 to be so fast by comparison.

https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32...

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

#152

Post by ssokolow »

MaxBarraclough wrote: post #130
rini17 wrote: post #124

Earlier quoted context omitted.

WASM only provides sandboxing. That is not the same as security nor it means runtime safety nor protection from undefined behavior.

> WASM only provides sandboxing. That is not the same as security The relevant Wikipedia article is named Sandbox (computer security) . > nor it means runtime safety nor protection from undefined behavior It puts stronger constraints on what mischief undefined behaviour can lead to, and guarantees that various runtime errors are handled with traps. [0] This isn't the same as a hard guarantee that execution will termi…

Speaking as someone who would love to see WebAssembly succeed as a cross-platform, cross-language way for me to write sandboxed plugins and CLI utilities, I do have to point out that, for out-of-browser use, WASM's MVP does regress various things:

* https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...

* https://www.usenix.org/system/files/sec20-lehmann.pdf

(eg. Under WebAssembly's memory model, dereferencing NULL=0 won't lead to a segfault.)

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

#153

Post by timClicks »

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

These binaries wouldn't provide the isolation that wasm provides... Although it's looks like they're essentially unikernels, which means that they could potentially be run per-invocation by a hypervisor.

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

#155

Post by MaxBarraclough »

ssokolow wrote: post #152
MaxBarraclough wrote: post #130

Earlier quoted context omitted.

> WASM only provides sandboxing. That is not the same as security The relevant Wikipedia article is named Sandbox (computer security) . > nor it means runtime safety nor protection from undefined behavior It puts stronger constraints on what mischief undefined behaviour can lead to, and guarantees that various runtime errors are handled with traps. [0] This isn't the same as a hard guarantee that execution will termi…

Speaking as someone who would love to see WebAssembly succeed as a cross-platform, cross-language way for me to write sandboxed plugins and CLI utilities, I do have to point out that, for out-of-browser use, WASM's MVP does regress various things: * https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la... * https://www.usenix.org/system/files/sec20-lehmann.pdf (eg. Under WebAssembly's memory model, dereferenci…

> Under WebAssembly's memory model, dereferencing NULL=0 won't lead to a segfault.

Thanks that's a curious one. It won't always lead to a segfault with a conventional compiler either, undefined behaviour being what it is. [0][1] Fortunately GCC can be asked to add such checks at runtime, [2] this approach could also be taken with WebAssembly.

[0] https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...

[1] https://blog.regehr.org/archives/213

[2] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h...

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

#156

Post by teleforce »

rodneyzeng wrote: post #8

wow, most likely, this means there would be a virus infective to all operating systems...

Not sure why you're being down voted, perhaps for telling the obvious?

I can foresee Morris Worm v2 coming up sooner rather than later but this time it won't just targeting UNIX systems. It is the obvious killer application for WORA library that use C, whether we like it or not.

On the bright side, for a start this probably can solve the many redundant VC++ compiler versions installation in a single computer just before we get to the 2030 VC++ compiler versions :-)

Anyway kudos to the library's author, when the late Dennis Ritchie invented C for portable OS, he had probably never envision how far it can be made portable.

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

#157

Post by saagarjha »

jart wrote: post #91
saagarjha wrote: post #79

Earlier quoted context omitted.

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

Not quite–kill is part of POSIX, and platforms that expose a libc interface must keep signal numbers consistent for applications. Syscall numbers need not be stable if they are not exposed, as is true on pretty much every platform but Linux.

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

#158

Post by vitiral »

thelastbender12 wrote: post #142
pwdisswordfish5 wrote: post #95

Earlier quoted context omitted.

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.

Would this not make the implementation inefficient?

IsWindows is likely a macro and therefore you have if(0) or if(1) which the compiler can easily optimize away.

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

#159

Post by thelastbender12 »

vitiral wrote: post #158
thelastbender12 wrote: post #142

Earlier quoted context omitted.

Would this not make the implementation inefficient?

IsWindows is likely a macro and therefore you have if(0) or if(1) which the compiler can easily optimize away.

I thought this implementation was meant for compile-once-run-everywhere usage, so I can't see how a compiler would do away with a this if-statement. Could you please say more?

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

#160

Post by jart »

thelastbender12 wrote: post #159
vitiral wrote: post #158

Earlier quoted context omitted.

IsWindows is likely a macro and therefore you have if(0) or if(1) which the compiler can easily optimize away.

I thought this implementation was meant for compile-once-run-everywhere usage, so I can't see how a compiler would do away with a this if-statement. Could you please say more?

The compiler keeps the branch. The branch doesn't impact performance because it's fully predictable and therefore costs less than 1 nanosecond. Please note however that fadvise() is a system call and the SYSCALL instruction o/s context-switch generally costs 1 microsecond, which is 1000x slower than any overhead incurred by the portability benefits Cosmopolitan offers.

You can however tune the build so the `IsWindows()` branch is dead code eliminated anyway:

    make MODE=tiny CPPFLAGS=-DSUPPORT_VECTOR=0b11111011
Basically unsetting the Windows bit causes the Windows polyfills to not be linked in your binary. It's only useful for making binaries tinier. So rest assured, if you find your 16kb APE .com binary to be too bloated, you can always use SUPPORT_VECTOR to squeeze it down to the order of a 4kb ELF executable. See: https://github.com/jart/cosmopolitan/blob/1df136323be2ae806f...
Post reply on HN