| |
| |
On 3/25/24 21:19 Greg Ercolano wrote:
On 3/25/24 12:21, 'Albrecht Schlosser' via fltk.coredev wrote:
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.
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.
Nope, putc() *can* be implemented as a macro, because the docs
explicitly state "... except that if it is
implemented as a macro it may ...". IMHO this says
clearly that it is allowed to implement putc as a macro.
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.
Unless this system function can be a macro. To clarify: I interpret
the docs of putc clearly that it can be a macro but I didn't see
clear evidence that putchar is allowed to be a macro. But I
definitely don't know the details. My point is to avoid this issue
by not naming the method like the system function.
What would be wrong with renaming the Fl_Terminal::putcha() method
to avoid name clashes in the first place?
Regarding your argument to emulate putchar(): putchar() puts a
single character (one byte!) and not a string (or a UTF-8 character)
in an output stream. This is more like Fl_Terminal::append*()
whereas Fl_Terminal::putchar() has additional arguments to write
that char or string at an arbitrary place in the display.
I'd say this difference alone qualifies for a different method name
(with or w/o taking the name clash into account).
And if calling it putc() would suffer similar
interference with the putchar()
macro, then we couldn't use putc() either, which is just bad.
Definitely not putc because putc is AFAICT allowed to be a
macro.
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'm not sure if it's broken. It is only broken if `[int] putchar(int
c)` *must not* be implemented as a macro. But this is not
mentioned in the pages I linked above. I just don't know if it is
allowed or not, that's one of the reasons why I asked for comments.
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.
They would also have to put "#undef putchar" after all include files
that defines the putchar macro (I mean: after the end of the list),
but they must not do it if another system include file depends on
that macro. It's just not doable!
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".
This workaround is not "workable" in user code. What if the user
wants to use Fl_Terminal::putchar(3args) and ::putchar(1arg) in the
same source file and the system's putchar is defined as a macro?
This doesn't work because you can't '#undef putchar'. #undef works
in src/Fl_Terminal.cxx only because we don't use ::putchar
in this file.
As long as we don't know which (maybe broken or not) systems define
putchar() as a macro we can't say what is correct. You would get
similar problems if you used Fl_Terminal::putc() and putc was legitimately
defined as a macro.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/606cdc55-7e0f-4eab-9ba4-46fabf3439b3%40aljus.de.
[ Direct Link to Message ] | |
|
| |
