sbuf has its own built-in printf logic, right? If so: would it make sense to refactor this code to use sbuf entirely?

The interesting thing about doing that would be that afterwards, ttyprintf() would only be called to write raw, pre-formatted buffers of data to the TTY. This can be done more efficiently, without calling into subr_prf.c at all.

It has it, yep. I guess I didn't realize this function was the only in-tree ttyprintf consumer.

Given that, yeah, I agree it makes a lot of sense to rip out ttyprintf, convert this code to sbuf, and use the more efficient tty plain string-writing routine.

@markj suggests we might just put this on the stack. I don't see any public stack_init KPI that doesn't allocate, but stack_create() is just an M_ZERO malloc, so perhaps zero-initialization would be adequate.

I'm less sure about dumping this one on the stack, especially given that PRINTF_BUFR_SIZE is somewhat flexible.

The stack(9) interface is a bit obnoxious here -- I'd like to be able to just invoke a single int-returning function, maybe with flags to allow grabbing a running stack, and not worry about checking SWAPPED/RUNNING or setting error to zero myself. But that is orthogonal to this enhancement.

Use stack_zero()?

I think I did it that way because each platform needs its own implementation and I only wanted to do it for x86. I don't disagree with the sentiment.

will fix