> On Sat, Mar 31, 2018 at 01:04:43PM -0600, Theo de Raadt wrote: > > The only worry about converting from iov to dprintf could be some > > atomicity requirement. I don't really see that in play here, I think > > the iov uses was simply for convenience. No other 'signalling interrupts' > > seem to be in play. > > My take was convenience, too, but in the commit you said it > was for atomicity: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/dd/misc.c?rev=1.9&content-type=text/x-cvsweb-markup > > Is there anything else we're worried about here? > > Rogue signals we can't anticipate leaving us with only partial > output on stderr?
Let's see. SIGINFO starts. Imagine if the buffering is small (I don't think it is). If it was small, there could be multiple writes to the sequence. SIGINT arrives. This will result in stderr output being a bit garbled. This isn't a huge problem in this circumstance, but it demonstrates why atomicity may matter. I think it can't occur because the default buffer size is large enough? ktrace can be used to see what the dprintf is doing.
