possible deadlock in ddout.c

[wehimwich]

While investigating #22, it became clear that the output display and logging for the TNX command uses logit(), creating a risk of a possible deadlock.

Background: The TNX functionality was added in 08249d9 (2001 Feb). In 54af15c (2016 Jul), ddout was fixed to not use class I/O with fserr, sterp, and erchk to eliminate the risk of a deadlock in high log entry volume situations, like multicast logging. However TNX use of logit() and reporting error bo -999 (also usinglogit())were apparently overlooked; they are still vulnerable to this. Probably only cls_snd() was looked for.

Still, the chance of a deadlock is pretty low. It could probably only happen in a high volume situation (active multicast logging) if the operator either uses TNX or changes to an existing log file big enough to cause a warning about its size (bo -999). Even then it is probably unlikely that the class I/O system would be at maximum capacity.

It looks like the most straightforward way to fix this in ddout.c is probably:

• make a C version of logen.f to format the log entry, only a subset is needed; it is probably easiest to start with logit.c, use of which would be replaced for this purpose
• add a C function to output the entry to the screen and the log; only a subset of the full, ddout functionality is needed; the same error checking/reporting for the disk writing is needed; these two C functions might be combined into one
• use a a direct log entry error message approach, like with logite.c, to format errors and then output, both accomplished using the above C function(s) in place of logit()
• change these errors in fserr.ctl to be placeholders ('this is a place holder for an error in ddout.c') to avoid accidental reuse

The particular bo errors reported by ddout would probably forego being filtered by TNX and sent to sterp and erchk, but with more code rearrange probably could be fully supported.