was it illumos that had woeful fork/exec latency?

or do just all OSes have that

That's not an especially productive question

it does not merit an answer

tsoome: omg how did you end up in audit_remote haha

that thing is awful

I tried so hard to use it

had to resort to cron jobs to kill auditd regularly to stop it getting into state where it just stops trying to send events out and turns into a brick

also it's what got me onto the NIS diffie-hellman + TDEA gss mech

tsoome: what do you mean by "gcc7 does not sign extend negative values"? how does gcc7 differ in that regard from other versions?

sensille gcc 4.4.4 was updated to do that, later versions are not. see also illumos.org/issues/2757. This was also one of the bricks on the path to drop sparc ...

→ BUG 2757: 32bit sparc direct system calls should not rely on compiler mannerisms (In Progress)

thanks

also note that the simple fix would be to drop 32-bit userland (which we should do anyhow) ;)

(except that dropping it would be huge amount of work of fixing bugs;)

Plus the only economically motivating factor behind SPARC support would be to preserve some legacy binaries you don't have source for, and odds are those are 32-bit

Then it will be like with any other vendor - you are stuck with that version and no updates (which such setups most likely will not install anyhow;) till the system will let magic smoke to leave.

looks like experimenting with cppcheck warned us of that horror in audit_remote back in 2014: "[usr/src/lib/auditd_plugins/remote/audit_remote.c:302]: (error) Invalid strncmp() argument nr 3. A non-boolean value is required."

"It appears the intent was to check if the strncmp results were == 0,

but the parens were put in the wrong place, and instead the length

argument to strncmp is "1 == 0", which evaluates to a value of 0, since

1 can never be equal to 0, unless the compiler is really broken. The

strncmp thus always returns 0, and code in the if block never executed."