bc VS wasmtime

https://git.gavinhoward.com/gavin/bc

It got me a C programming job that had nothing to do with the side project.

I would say that it only helped me in the interview process, but it did so in two ways:

* I could actually answer C-related questions on top of the more generic questions.

* It showed that I had skill in C.

> Imagine this code...In a world where you can't optimize based on UB assumptions, x can change in the body of f.

Yeah, so you allocate space on the stack (which is free, by the way, because space has to be allocated anyway for the new function's frame), store to it, and load from it.

An extra store and an extra load. Of stack space that was probably already in cache anyway.

So what? What a miniscule price to pay.

> You don't need to share memory across threads to opt in to data races. You can access whatever you want with pointer arithmetic if you want to be correct in the presence of UB.

So C should have bounds checks and define a failing bounds check as an abort. And then such optimizations could be correct. That's what so many other languages do, and it works.

> Or this code...f could be deleted. This could be UB.

Do you mean freed?

Yes, that could be UB. But the compiler should never say, "Oh, well, f could be freed here, so I'm just going to delete the `f->do()` call."

Bad example because compilers don't currently take advantage of it. They day they take advantage of that is the day that I quit programming.

> I do not believe this. I am one of the people at my company fighting to spend performance to buy safety.

Ha! I do not believe you at all! You are okay with compilers taking advantage of UB to elide a store and a load.

The only way you are telling the truth is if your company is full of malicious compiler authors.

> I just don't believe that the principle of least surprise can be implemented in the standard in the way some people say

It totally could. C could even have bounds checks without changing the ABI. They just don't.

> I don't believe that UB is totally unique from other forms of incorrectness in a way that should cause us to behave very differently about it.

It's the only form of incorrectness that:

* Will destroy everything.

* That compiler authors claim they have a right to take advantage of.

Yeah, we definitely should treat it differently. You are dead wrong.

> Do you run your production binaries with all of the sanitizers enabled?

No, because I don't work in the industry.

But in my personal code, I wrote my own bounds checks and enabled them. In C. In release mode. All your talk of "but you could make a pointer to anywhere" doesn't happen in my code.

I use structured concurrency to allocate and free items in only one place, in the same stack frame. When threads are created, they prevent the creating thread from returning from the stack frames that the children may have gotten pointers to.

I fuzz like you wouldn't believe and make sure all paths come back clean in ASan, UBSan, TSan, and Valgrind, including memory leaks.

I add all unique paths from fuzzing to my test suite.

I'm going to write my own malloc() that will have double-free and use-after-free checks.

I use unsigned types to avoid signed overflow, and such unsigned types more easily trip the bounds checks when they overflow because the bounds checks only need one condition.

Tell you what: I would like you to take version 6.7.2 of my bc [1] and get it to execute UB. Any UB is fine.

If you do, I'll enable sanitizers on my release builds of all of my software.

But you won't, and that's why I can forego sanitizers on release builds: I do enough work to ensure that UB won't happen.

And that's why I use unsigned types. Your bellyaching about their poor optimization will not change that.

[1]: https://git.gavinhoward.com/gavin/bc

While Julia starts scared and ends up feeling better, I've only gotten more scared of Unix signals over time.

Context: I've written a robust command-line utility [0] that must handle signals, and unlike most utilities that are I/O-bound, mine is CPU-bound.

An I/O-bound utility can easily use signalfd() (subject to the gotchas in the "signalfd() is useless" post that Julia links to, which you should also read). signalfd() will work for I/O-bound utilities because it turns those signals into I/O. Perfect.

However, in a CPU-bound program, signals are used specifically to interrupt execution. This is, to put it mildly, as difficult as writing code for interrupts in the embedded space. Why? Because that's really what you're doing: handling an interrupt that can happen at any time.

My solution was something I wish on no one: I used setjmp() and longjmp().

Horrors!

Yep. And it gets worse: I had to longjmp() out of the signal handler.

AH!

And it gets worse: to ensure that there were no memory leaks, I had to keep a stack of jmp_bufs and manually jump to each one, which would be in a function where memory had to be cleaned up.

Cue screams of bloody murder

You may insist that longjmp()'ing out of signal handler is not allowed; it actually is [1], but unlike most other "async-signal-safe" functions, you need to ensure you don't interrupt a syscall or other code that is not async-signal-safe.

So it gets worse: I have a signal lock that the signal handler checks. If it's not locked, the signal handler will longjmp() out of the signal handler. If it is locked, the signal handler sets a flag and returns. Then the code that unlocks signals checks for the flag and does a longjmp() if it's set.

He's dead, Jim!

I have another project that is a framework in C. This framework needs to handle signals for clients. It has to be general, so it has to handle CPU-bound clients. So I had to implement the same thing. I was able to make it easier, but it is also harder because I have that one thing that messes up every Unix API: threads.

Nuclear mushroom cloud

So should you be scared? It depends; if you can get away with signalfd() and know it's gotchas, maybe not.

But if you need anything more complex, yes, be very afraid.

[0]: https://git.gavinhoward.com/gavin/bc

[1]: https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...

I am a programmer and a blogger, like the author. Unlike the author, I do not monetize my blog in any way (or I assume he does on Substack).

The author is both right and wrong, just about different things.

First, he assumes GPT will get exponentially better. If that were true, all cars would be full self-driving already. GPT will have an S curve or Sigmoid function.

Second, he assumes that GPT will always be able to produce things from differing voices well. However, as more data is used, these bots will only become more homogenous. You can see clues of this when it managed to make a Biggie Smalls rap, but did not with Woody Gunthrie, whose data is probably closer to the mainstream than Biggie's. (This is a gut feeling; could be wrong.)

Third, as things become more of the same bot-like feeling, even from people, those who have their own voice and touch will stand out more. You can see this in his essay, versus the two written by the bot. The voice of the bot ones feels more stilted to me. His feels more natural.

What people need to do is to develop their own voice and touch.

In writing, develop your voice. Write without help. Write a lot. Create a blog. Put random stupid stuff there. Let yourself rant. That random stupid stuff and those rants will not be mainstream, and if it's stupid and ranty, you won't have to care about quality. That lack of care will let you have fun, and that fun will become your voice.

This is how I developed my voice with my blog.

In code, develop your touch. Don't just code; design. Think about concepts. Think about UX and workflows. Iterate until everything is great. Then design the implementation and iterate until everything fits. Then, and only then, code. But as you code, iterate the design to remove things that no longer fit and add things that do. Dogfood your software. Use it for everything you can, even things that don't fit well. Iterate and change some more to make your dogfooding easier.

The end result will be software that is easy-to-use and fits the users' needs well. That fit will be your touch.

This is how I developed my touch with my most well-known project: `bc`. [1]

But you don't even need to stop there. With my `bc`, I spent time supporting users and implementing things for them. Obviously, I still designed changes before implementing them, but I listened to my users and gave them what they wanted within the constraints I had.

The end result is a `bc` that can act like the GNU `bc` or the BSD `bc`, whichever you want. It can also be its own thing with extra features.

Listening to users is another human touch. Make use of it. In fact, that's where I will make a living from my current project: my support for it will be best-in-class [2], and that's something GPT can never replicate because it cannot replicate my brain, my voice, and my touch, even when trained on my writing.

In other words, the author is write that the 90% is useless, but those 90% were the ones where you were at least partially imitating a bot anyway. Those 10% are the human traits.

If you want to have useful skills, be a human, not a fleshy bot.

Footnote: I feel bad for anyone that gets my code or writing as output from GPT. My code fits my head and no one else's. It also uses custom API's that don't exist anywhere else, which means such output would be useless. The same goes for my writing, though to a lesser extent.

[1]: https://github.com/gavinhoward/bc

[2]: https://github.com/gavinhoward/bc/issues/66

Username checks out because you missed the point.

Yes, I know calculators can encourage people to not think; I should know because I wrote one. [1]

But the current "AI" tech is so much worse on that front. It's a difference of degree, and that degree does matter.

By the way, when I was learning to fly helicopters [2], I used my calculator to calculate weight and balances, but I also did it by hand!

[1]: https://git.gavinhoward.com/gavin/bc

[2]: https://gavinhoward.com/2022/09/grounded-for-life-losing-the...

Shameless plug: my bc [1] has a random number generator that is much higher quality than the shell one. Because it's bc, you can generate random numbers of any size, and you can generate random reals as well.

It is also seeded.

[1]: https://git.gavinhoward.com/gavin/bc

>Notice that I said to find a memory bug in a release, not just any commit.

You did not say anything of the sort.

>But I also said to find one in the program, not the library.

You did not say anything of the sort.

You said:

>>The code is my `bc`. [1]

>>Find a memory bug, any memory bug, in my `bc` after 1.0.

>>[1]: https://git.yzena.com/gavin/bc

But okay, let's acknowledge the moved goalposts.

>I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0.

Tell me what subset of the repo named "bc" you consider to be "the program"

>Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.

Crates like tokio-signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans.

Surprisingly, it is possible to do exactly what the author wants. I know because I've done it. However, it is as complicated as the author says it is.

The project in question is my `bc` [1].

Until version 3.0.0 [2], it used a "yield" architecture: every loop it could enter had a check for a signal. This got tedious, so I decided to make the jump to instant-ish reset.

I was lucky in several ways. First, `bc` is a really good program to reset; you just stop it executing, wipe all data away, and ask for more input with a blank slate. Second, it is single-threaded.

Nevertheless, it was still really difficult, especially to have no memory leaks.

First, I had to learn how to use `sigsetjmp()` and `siglongjmp()`. Yep, that was how I was going to do this. Once I learned, I implemented a stack of `sigjmp_buf`'s. Then, when a signal happens, each individual `sigjmp_buf` is used. This allowed me to properly free memory on the way.

In essence, if a function had allocated memory, then it would push a `sigjmp_buf` on the stack, and then when a `siglongjmp()` happened, execution would go to a label where that memory would be freed before continuing the jump series.

Then I implemented signal locks. It is safe to `siglongjmp()` out of signal handler, as long as it didn't interrupt code that was non-async-signal-safe. So I used signal locks for that, and when "unlocking" the lock, it would check for a signal and jump. And if the signal handler sees a lock, it just sets a flag and returns.

Then I had to go through my codebase and protect every bit of non-async-signal-safe code with locks. It was tedious, but the result is fantastic.

Nowadays, I'm working on a threaded build system, and when it gets SIGINT, it sends a message to threads to stop as soon as their children are done. If it receives a second, it just exits.

So yeah, every application is different, but it is possible.

[1]: https://git.yzena.com/gavin/bc

[2]: https://git.yzena.com/gavin/bc/src/branch/master/NEWS.md#3-0...

You're welcome. :)

> I've bookmarked your gitea bc repo, not just for bc, but as an example of a neatly managed FOSS project, like providing performance comparison, fuzzing, project structure, the fact of using self-hosted gitea itself, etc

Thank you! It's good to know that my project is actually good; sometimes I wonder if I am just full of myself. XD

> Skimming through [1], I see neither of Winget [2] nor Chocolatey [3] have any `bc` implementations as of yet. Maybe you can send them a PR? It may help adoption in other distros in the future.

I will do that. However, I might wait until I accept a PR that was just made [1] that will fix issues on Windows. I am not good at Windows, so there are problems.

> Hope your implementation wins ;)

Thank you. :)

[1]: https://github.com/gavinhoward/bc/pull/38

Just a documentation change, fortunately:

https://github.com/bytecodealliance/wasmtime/commits?author=...

They've submitted little documentation tweaks to other projects, too, for example:

https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...

I don't know whether this is a formerly-legitimate open source contributor who went rogue, or a deep-cover persona spreading innocuous-looking documentation changes around to other projects as a smokescreen.

WebAssembly is extremely portable. WebAssembly runs on: all major web browsers, V8 runtimes like Node.js, and independent Wasm runtimes like Wasmtime, Lucet, and Wasmer.

cpu: 4 disk: 60 memory: 12 arch: host hostname: colima autoActivate: true forwardAgent: false # I only tested this with 'docker', not 'containerd': runtime: docker kubernetes: enabled: false version: v1.24.3+k3s1 k3sArgs: [] network: address: true dns: [] dnsHosts: host.docker.internal: host.lima.internal # Added: # - containerd-snapshotter: true (meaning containerd will be used for pulling images) docker: features: buildkit: true containerd-snapshotter: true vmType: vz rosetta: true mountType: virtiofs mountInotify: false cpuType: host # This provisioning script installs build dependencies, WasmEdge and builds the WASM runtime shims for containerd. # NOTE: this takes a LOOONG time! provision: - mode: system script: | [ -f /etc/docker/daemon.json ] && echo "Already provisioned!" && exit 0 echo "Installing system updates:" apt-get update -y apt-get upgrade -y echo "Installing WasmEdge and runwasi build dependencies:" # NOTE: packages curl, git and python3 already installed: apt-get install -y make gcc build-essential pkgconf libtool libsystemd-dev libprotobuf-c-dev libcap-dev libseccomp-dev libyajl-dev libgcrypt20-dev go-md2man autoconf automake criu pkg-config libdbus-glib-1-dev libelf-dev libclang-dev libzstd-dev protobuf-compiler apt-get clean -y - mode: user script: | [ -f /etc/docker/daemon.json ] && echo "Already provisioned!" && exit 0 # # Setting vars for this script: # # Which WASM runtimes to install (wasmedge, wasmtime and wasmer are supported): WASM_RUNTIMES="wasmedge wasmtime wasmer" # # Location of the containerd config file: CONTAINERD_CONFIG="/etc/containerd/config.toml" # # Target location for the WASM runtimes and containerd shims ($TARGET/bin and $TARGET/lib): TARGET="/usr/local" # # Install rustup: # echo "Installing rustup for building runwasi:" curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain none -y source "$HOME/.cargo/env" # # Install selected WASM runtimes and containerd shims: # [[ -z "${WASM_RUNTIMES// /}" ]] && echo "No WASM runtimes selected - exiting!" && exit 0 git clone https://github.com/containerd/runwasi echo "Installing WASM runtimes and building containerd shims: ${WASM_RUNTIMES}:" sudo mkdir -p /etc/containerd/ containerd config default | sudo tee $CONTAINERD_CONFIG >/dev/null for runtimeName in $WASM_RUNTIMES; do case $runtimeName in wasmedge) echo "Installing WasmEdge:" curl -sSfL https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | sudo bash -s -- -p $TARGET echo echo "`wasmedge -v` installed!" ;; wasmtime) echo "Installing wasmtime:" curl -sSfL https://wasmtime.dev/install.sh | bash sudo cp .wasmtime/bin/* ${TARGET}/bin/ rm -rf .wasmtime echo "`wasmtime -V` installed!" ;; wasmer) echo "Installing wasmer:" curl -sSfL https://get.wasmer.io | sh sudo cp .wasmer/bin/* ${TARGET}/bin/ sudo cp .wasmer/lib/* ${TARGET}/lib/ rm -rf .wasmer echo "`wasmer -V` installed!" ;; *) echo "ERROR: WASM runtime $runtimeName is not supported!" exit 1 ;; esac cd runwasi echo "Building containerd-shim-${runtimeName}:" cargo build -p containerd-shim-${runtimeName} --release echo "Installing containerd-shim-${runtimeName}-v1:" sudo install ./target/release/containerd-shim-${runtimeName}-v1 ${TARGET}/bin sudo ln -sf ${TARGET}/bin/containerd-shim-${runtimeName}-v1 ${TARGET}/bin/containerd-shim-${runtimeName}d-v1 sudo ln -sf ${TARGET}/bin/containerd-shim-${runtimeName}-v1 ${TARGET}/bin/containerd-${runtimeName}d echo "containerd-shim-${runtimeName} installed." cd .. echo "[plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.${runtimeName}]" | sudo tee -a $CONTAINERD_CONFIG >/dev/null echo " runtime_type = \"io.containerd.${runtimeName}.v1\"" | sudo tee -a $CONTAINERD_CONFIG >/dev/null done echo "containerd WASM runtimes and shims installed." # # Restart the systemctl services to pick up the installed shims. # NOTE: We need to 'stop' docker because at this point the actual daemon.json config is not yet provisioned: # echo "Restarting/reloading docker/containerd services:" sudo systemctl daemon-reload sudo systemctl restart containerd sudo systemctl stop docker sshConfig: true mounts: [] env: {}

When you say wasm container, you mean something like wasmtime that provides a non-browser wasm runtime?

https://github.com/bytecodealliance/wasmtime

We can't run this directly from the command line unless we install some runtime like wasmtime:

The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt, but I'm surprised someone like yourself literally building a competitor spec isn't following what they are doing closely.

Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.

If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I can see that being a technical win. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime today), nor will it run in browsers, because they're not going to expose WASIX - they're going to go with the standards instead. so far you're the only person I've met that thinks exposing POSIX fork() to WASM is a good idea, seemingly because it just lets you build existing apps 'without modification'.

Comical you accuse me of being polarizing, while pushing for your world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall.

[0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...

[1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...

[2] https://bytecodealliance.org/articles/webassembly-the-update...

[3] https://github.com/bytecodealliance/wasmtime/pull/7285

[4] https://github.com/WebAssembly/shared-everything-threads

Thanks for the question!

Spin could definitely run in more places than what we have pre-built binaries for. Specifically, we could run on all platforms Wasmtime supports today (https://github.com/bytecodealliance/wasmtime/releases/tag/v1...), including RISC and S390X, for example.

And while we have been experimenting a bit with running Spin on RISC, we haven't really had the bandwidth or requirement to build a production build for those yet.

Are you interested in a specific operating system or CPU architecture? Would love to understand your scenario.

> I used to think we'd eventually get to capability based security, but now I see we'll always be stuck with application permission flags, the almost worthless bastard cousin, instead.

My hope is that WASI will introduce capability based security to the mainstream on non-mobile computers [0] - it might just take some time for them to get it right. (And hopefully no half-baked status-quo-reinforcing regressive single—runtime-backed alternatives win in the meantime.)

[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

WasmTime finished finished the RFC for the implementation details in June: https://github.com/bytecodealliance/wasmtime/issues/5032

[3]: https://github.com/bytecodealliance/wasmtime/pull/2611