Re: prefer dprintf() over snprintf()+write()
> Actually, plain old printf should be OK in ping.c since buffering > is disabled for ping -f. If you want to keep dprintf(), I think > we can lose the setbuf() call. Whatever you decide, it would > be nice to make ping6.c match. No, disagree strongly. ping is doing this inside a signal handler. Our snprintf has been verified (sans floating point) for use in signal handlers. Other libc/stdio functions did not receive any study, because their use in a signal handler is unacceptable. We should never place anything like this in signal handler. Even if unbuffered printf is safe, someone might copy this code to elsewhere and not pick up on the nuanced use. Also maybe it is safe on OpenBSD... it surely is not elsewhere... and people do copy our code.
Re: prefer dprintf() over snprintf()+write()
Ah, I didn't realize that pinger() was still called via a signal handler in ping. It looks like ping6 is better in this regard. - todd
Re: prefer dprintf() over snprintf()+write()
> Ah, I didn't realize that pinger() was still called via a signal > handler in ping. It looks like ping6 is better in this regard. ping and ping6 need to be merged, as happened to traceroute. First step: make all ping6's options match ping options. Rename ping6 options with wild abandon if ping has a similar option. Don't encode backwards compat behaviour for those options in ping6; throw them out the window. However, each time ping6's guts are found to better, use the ping6 guts. The engine is a bit better. This should have happened years ago already. Every year of realtime, this gets harder to pull off; there will be more resistance against change.
Re: prefer dprintf() over snprintf()+write()
Actually, plain old printf should be OK in ping.c since buffering is disabled for ping -f. If you want to keep dprintf(), I think we can lose the setbuf() call. Whatever you decide, it would be nice to make ping6.c match. - todd
