In ROM 2.4 (and actually I just checked also in MERC but not Diku Alpha), there's a globally declared char in db.c called log_buf. It seems to be used mainly log_string/wiznet log commands throughout the mud (although, in a minority of the logging commands).

I have a few questions:

1.) Is the rationale behind declaring this globally and then re-using it the fact that it's already allocated so it's quicker when logging?
2.) I haven't had any issues, nor have I experienced any ever but is there a chance this could be a race condition where one log command overwrites log_buf before another writes it out (since it's being shared)?
3.) Is there a problem I'm missing with just axe'ing it and declaring the "char buf"'s locally or use log_f's where they're needed (which is what I'm going to do unless I'm missing something obvious)?

Just curious if anybody has any insight like, that's just how they rolled in 1993 to eek a little more performance out. ;-)

Very unlikely.
The rational might have been, or still is, that two or more different functions added to it before printing/sending it.
Which isn't a very good programming practice.


No race condition unless you are multi-threading. ;-)



No problem, unless you run into the situation above with multiple functions adding to it.
In that case you'll allocate in on the stack in the outermost function and pass it along to the called functions.

Thanks for the input! That does make sense about the race conditions, I forget it's truly running sequentially.