When running gcc in a parallel build or multi-threaded environment, I run into cases where gcc's error output gets broken in the middle of line or worse, individual gcc error output lines from different threads/processes get broken up and mixed together. While I would fully expect interleaving of LINES in a multithreaded environment with a shared file descriptor (stderr) I would have hoped that the output of each error LINE would be atomic. I eventually tracked this down into libcpp/errors.c where I saw that the output of error lines is often broken up into many output calls to stderr. I believe POSIX dictates that each individual output call is atomic with respect to other threads or processes sharing the same file descriptor but of course if a single error line is output using numerous fputs(), fputc() and *fprintf() calls then POSIX provides no guarantee that the line will appear unbroken in the final output. I have filed this as "enhancement" since I'm not prepared to call the lack of "atomic line output" a bug, but it would sure be a nice feature to have. Otherwise in parallel build environments one sometimes get fragments of error message lines intermixed in stderr and it can be quite confusing. Thanks.
Really libcpp (the C preprocessor) should be using the normal diagnostic part of GCC and not its own.
cpplib does now use GCC's diagnostic.c, so if there is a bug here any more it is not a preprocessor one. It looks like diagnostic.c (in turn using pretty-print.c) will write the diagnostic in one fputs call, then the final newline in an fputc call, then flush the stream, so it's not yet using the minimal number of stdio calls - though even with the minimal number of such calls that doesn't and can't guarantee that multiple write() calls aren't used underneath by libc.