"C is a simple language. This is fact I agree with and appreciate. It is the reason for C's endurance. If someone posts a patch or submits a PR to a codebase written in C, it is easier to review than any other mainstream language. There is no spooky at a distance."
Today I realized #Go and #Rust both have panics instead of exceptions and both originate from the second half of the 2000s.
These facts are now mentioned in https://gato-lang.dev/
If you have experience with Go or Rust, I'm interested in your thoughts on the lack of exceptions in these languages. It looks to me like an attempt to simplify things that eventually backfired, as evidenced for example by https://www.crowdstrike.com/en-us/blog/dealing-with-out-of-memory-conditions-in-rust/
@Changaco In non-garbage collected languages like #Rust or C++ the problem with exceptions (and panic is kind of exception with limited options for handling) is that the stack unwinding is non-deterministic and code heavy. So in contexts like embedded systems, very problematic (that's why on embedded we turn off exceptions in C++). With handling errors, the cost is explicit in the code.
#C++23 introduced `std::expected<>` for that reason, but SL doesn't use it yet for anything.
maco
boosted
I want to be your next #FediHire ! I've been a programmer since 1985 (as a child), I've been an IT professional since 1995 (pulling wires and swapping cards and configuring MS Windows). I graduated from University of Arkansas Fayetteville with a BS in CS in December of 2003. A full resume is available.
I currently require a 100% remote position. I cannot relocate from Cove, #Arkansas. I would prefer W-2 employment with a base salary of at least 130k USD/yr, plus some sort of retirement offering (401k or similar) and healthcare benefits (HDCP + HSA or similar).
I prefer something where I can be a high-performing individual contributor: reading, writing and improving source text the majority of my day, with some time spent knowledge-sharing with other developers -- learning and teaching. I'd like to work with #Haskell, #Purescript, or #Idris as the primary source language. I've previously delivered value in Haskell, #Javascript, #SQL, #Python, #Scala, #Java, #C, and #C++ among others. I can be productive in almost any language (no PHP, please; I promised myself never again).
I want to be your next #FediHire ! I've been a programmer since 1985 (as a child), I've been an IT professional since 1995 (pulling wires and swapping cards and configuring MS Windows). I graduated from University of Arkansas Fayetteville with a BS in CS in December of 2003. A full resume is available.
I currently require a 100% remote position. I cannot relocate from Cove, #Arkansas. I would prefer W-2 employment with a base salary of at least 130k USD/yr, plus some sort of retirement offering (401k or similar) and healthcare benefits (HDCP + HSA or similar).
I prefer something where I can be a high-performing individual contributor: reading, writing and improving source text the majority of my day, with some time spent knowledge-sharing with other developers -- learning and teaching. I'd like to work with #Haskell, #Purescript, or #Idris as the primary source language. I've previously delivered value in Haskell, #Javascript, #SQL, #Python, #Scala, #Java, #C, and #C++ among others. I can be productive in almost any language (no PHP, please; I promised myself never again).
🕹️ Developing a Retro-Roguelike Game for Multiple Platforms in C
｢ The journey began with TRSE, a development environment supporting a huge number of vintage computer systems. My plan was to develop a text-based roguelike that could run on various hardware by compiling code for each target ｣
When writing a #daemon that follows best practices (handling of #detaching with a locked #pidfile, and #SIGHUP for #configuration #reload), an extremely simple "init script" will do (reliably!) for #FreeBSD's mewburn-rc. 😎
I'm trying to add "genric" #signal handling to #poser. Ultimate goal is to provide a way for #swad to handle #SIGHUP, although signal handling must be done in poser's main event loop (signals are only ever unblocked while waiting for file descriptor events).
Okay, I could just add explicit handling for SIGHUP. But a generic solution would be nicer. Just for example, a consumer might be interested in #SIGINFO which doesn't even exist on all platforms ... 🤔
Now, #POSIX specs basically just say signal constants are "integer values". Not too helpful here. Is it safe to assume an upper bound for signal numbers on "real world" OS implementations, e.g. 64 like on #Linux? Should I check #NSIG and, if not defined, just define it to 64? 🙈
Just released: #swad 0.5
swad is the "Simple Web Authentication Daemon", meant to add authentication using a #cookie and a #login form to your reverse proxy. It's designed for #nginx' "auth_request" module. It's written in pure #C with very few external dependencies (zlib, and depending on build options OpenSSL/LibreSSL and #PAM).
And with this release, it also allows guest logins using the crypto puzzle you may already know from #Anubis!
Read more in the release notes, grab the .tar.xz and build/install it 😎
And here's the "real world" usage 😎
So now I can give ppl a #login for #swad with a monthly changing password to access my #poudriere logs. Hopefully still keeps the #bot hordes out.
And documented.
I guess I should test a while before releasing this with #swad 0.4
https://github.com/Zirias/swad/commit/70607960709ae17833cf31192c702f4017d89b44
Just released: #swad v0.3!
https://github.com/Zirias/swad/releases/tag/v0.3
swad is the "Simple Web Authentication Daemon", your tiny, efficient and (almost) dependency-free solution to add #cookie + login #form #authentication to whatever your #reverse #proxy offers. It's written in pure #C, portable across #POSIX platforms. It's designed with #nginx' 'auth_request' in mind, example configurations are included.
This release brings a file-based credential checker in addition to the already existing one using #PAM. Also lots of improvements, see details in the release notes.
I finally added complete build instructions to the README.md:
https://github.com/Zirias/swad
And there's more documentation available: manpages as well as a fully commented example configuration file.
I need some advise: Is there a good portable and free (really free, not GPL!) #implementation of #bcrypt in #C around?
There's #OpenBSD source I could use, but integrating that would probably be quite a hassle...
Background: I want to start creating a second credential checker for #swad using files. And it probably makes sense to support a sane subset of #Apache's #htpasswd format here. Looking at the docs:
https://httpd.apache.org/docs/current/misc/password_encryptions.html
... the "sane subset" seems to be just bcrypt. MAYBE also this apache-specific flavor of "iterated" MD5, although that sounds a bit fishy ...
Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...
... in good old #C! 😎
Well, at least sort of.
* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.
* I can't do anything about the basic language syntax, so some boilerplate comes with using it.
* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)
But then ... async/await in C! 🥳
Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html
I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad. 🥳
The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.
Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...
The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution. 😎
In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c
Found an issue and fixed it. Turns out destroying my #Process instance when the child exited was wrong, there could still be unread data in the #pipe. But then, only waiting for #EOF on the pipe was equally wrong ...
Now the code does the only reliable thing:
* When the child terminated, close the pipe for stdin immediately if one was present
* Only destroy the process instance once the child terminated AND the pipes for #stdout and #stderr (IF they were present) found EOF.
Committed now:
https://github.com/Zirias/poser/commit/18051d9da0ba7e4caf2882828e5706e35d419f94
And here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___process.html
My testing code also had to change a bit and now makes for a completely pointless and cute wrapper around /bin/ls 🙈 😂
On a #coding mission to improve my #poser lib 😎.
In the current implementation of #swad, I don't really like that I need an extra thread, just to control a child #process. A first piece to add to poser is generic "child process support", which I'm testing right now. I realized I could reuse my #Connection class, which was built for #sockets, but works just as well with #pipes 🙃
TODO now is mostly testing. See screenshots for some mimimal testing code and its output ... would you like this kind of interface? 🤔
About the #random thingie ... I need random data in #swad to generate unpredictable #session IDs.
I previously had an implementation trying the #Linux-originating #getrandom if available, with a fallback to a stupid internal #xorshift#PRNG, which could be disabled because it's obviously NOT cryptographically secure, and WAS disabled for the generation of session IDs.
Then I learned #arc4random is available on many systems nowadays (#FreeBSD, #NetBSD, even Linux with a recent-enough glibc), so I decided to add a compile check for it and replace the whole mess with nothing but an arc4random call IF it is available.
arc4random originates from #OpenBSD and provides the only sane way to get cryptographically secure random data. It automatically and transparently (re-)seeds from OS entropy sources, but uses an internal CSPRNG most of the time (nowadays typically #ChaCha20, so it's a misnomer, but hey ...). It never fails, it never blocks. It just works. Awesome.
I revisited that, AGAIN. Getting #random data in #poser now has yet another fallback, in case we don't have #arc4random and we also don't have #getrandom: read from /dev/random and/or /dev/urandom, "old style" 🙈. Still better to try this before resorting to a simple little #xorshift.
In the best case — arc4random found — this is still all the code of PSC_Random_bytes() 😆:
arc4random_buf(buf, count);
return count;
https://zirias.github.io/poser/api/latest/class_p_s_c___random.html
Nice, #threadpool overhaul done. Removed two locks ( #mutex) and two condition variables, replaced by a single lock and a single #semaphore. 😎 Simplifies the overall structure a lot, and it's probably safe to assume slightly better performance in contended situations as well. And so far, #valgrind's helgrind tool doesn't find anything to complain about. 🙃
Looking at the screenshot, I should probably make #swad default to two threads per CPU and expose the setting in the configuration file. When some thread jobs are expected to block, having more threads than CPUs is probably better.
https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d
More #poser improvements:
* Use arc4random() if available, avoids excessive syscalls just to get high-quality random data
* Add a "resolver" to do #reverse#DNS lookups in a batch, remove the reverse lookup stuff from the connection which was often useless anyways, when a short-lived connection was deleted before resolving could finish 🙈
As a result, #swad can now reliably log requests with reverse lookups enabled 🥳
