Hi all,

TL;DR: I believe we should rename Fl_Terminal::putchar() to something that doesn't conflict with the global function name putchar() which *may* be defined as a macro.

Yuck.

We could rename it to putc() which, if POSIX says needs to be implemented
as a function (and not a macro), should be allowed. But, that still might cause
problems with the #define putchar() macro calling the wrong thing, for instance,
in a derived class where prefixes that would bypass the macro (like "->" and ".")
aren't needed.

There's a reason the method is implemented as putchar(), to emulate the
putchar() function within the widget. This should be legal to do, especially
as a class method.

And if calling it putc() would suffer similar interference with the putchar()
macro, then we couldn't use putc() either, which is just bad.

For this reason I'm not sure we should have to chase arguably broken platforms
like this. (If POSIX said "must be a macro" then I'd change my mind.)

I'd instead leave it to the application programmer to solve, like any other
messy platform specific issue, by adding "#undef putchar" before
"#include <FL/Fl_Terminal.H>" and similarly handle their use of putchar()
to non-fltk modules.

My feeling is take a stand and push the problem resolution back upstream
to its source, perhaps documenting the issue and how to workaround, assuming
the workaround is "workable".