@david_chisnall

You've built a argument on the assumption of binary incompatibility, but in fact there was none.

There was no layout change nor symbol name changes.

The struct layout stayed entirely the same. The struct definition merely moved from one header to another and replaced the declarations of some members with external library types rather than their underscored aliases that standard headers use.

The thing that would have introduced binary incompatibility, which #OpenBSD has had to deal with this year, #FreeBSD had already done 7 years earlier back in 2001, and is still the case now.

By 2008, it was just moving struct definitions out of a standard header and removing "inline" macros. The one thing in base that that broke in 2008 (because of *source* incompatibility) went away in 2011, and Jordan Hubbard patched some stuff in ports a decade ago.

It is entirely feasible in 2025 for FreeBSD to regain parity with OpenBSD quite simply.

#stdio #StandardC #OpaqueTypes

This, btw, was yet another reminder of the horrible can of worms #stdio's #buffering is.

I created a little tool running as a child process to do the *actual* #PAM authentication, so it will be possible to have this run as root while the real service drops all privileges. This little tool uses a simple line-based protocol for communication on stdin/stdout. It worked well when testing directly on the terminal.

On the first real test though, my service just went hanging. 🙄 I suspected a deadlock caused by pthread mutexes. Wasted quite some time looking into that. Then I finally realized communication over the pipes was stalled.

Ok, just set buffering mode to "line buffering" after fdopen'ing the #pipe. Turned out that didn't help either. I *assume* that even in the child process, the stdio streams automatically created on the pipes were somehow fully buffered. But at that point, I was really fed up with trial and error and rewrote the whole mess to do I/O using plain #POSIX APIs (read, write), sidestepping any buffering. Worked like a charm. 🙈

#C #coding

@lattera
I'm not an OpenBSD developer, so I would be mis-understanding, but if I design the pledge functionality, maybe I would do the same.

close() is basically tied with open(), with some exceptions, stdin, stdout and stderr.
These 3 are opened on process initialization, by default for at least programs by C.

My guess (never actually used, though) with pledge is that it's not initialized on compilation time, but runtime. So the default 3 "files" are already opened when the code initializes pledge. And in some cases, any of there 3 are closed after the process starts. More, these 3 belongs to stdio. So close() should require stdio, or something it belongs to. Just corelated open() is hidden in crt1.o made it overly confusing.

Correct me if I'm mis-understanding.

#OpenBSD #pledge #close #stdio