imacarthur wrote: > > On 21 Dec 2009, at 8:31, Albrecht Schlosser wrote: > >> The events argument is tested for POLLIN etc., but is defined to >> use the FL_READ etc. constants in the interface documentation. >> >> <http://www.fltk.org/doc-1.3/classFl.html#76b6c3f9043d22034a47177914fd4054> >> >> >> Now, looking at this again, I remember that I once wondered why the >> code doesn't use the FL_* constants instead of declaring its own, >> but maybe this is for some "code compatibility" with other platforms, >> where the POLL* constants are defined. >> >> Conclusion: >> >> IMO the _correct_ solution is to replace POLL* with FL_* (see above) >> and *not* to define them in Fl_win32.cxx at all. The second best >> solution would be to undefine and redefine them, but I think that >> this would only lead to confusion. >> >> We'll also have to check this (matching POLL* an FL_*) for other >> platforms as well... > > Do the other platforms actually define these values, though? > It looks (on a very cursory check by me, so NOT definitive) that we > always define these values?
I didn't have the time to investigate this before, that's why I wrote that we need to check it. Now I did a short grep in src/*.c*, and it turns out that we define them for all platforms: Fl_mac.cxx:221:#define POLLIN 1 Fl_mac.cxx:222:#define POLLOUT 4 Fl_mac.cxx:223:#define POLLERR 8 Fl_win32.cxx:236:# define POLLIN 1 Fl_win32.cxx:237:# define POLLOUT 4 Fl_win32.cxx:238:# define POLLERR 8 Fl_x.cxx:72:# define POLLIN 1 Fl_x.cxx:73:# define POLLOUT 4 Fl_x.cxx:74:# define POLLERR 8 > In any case, I think we could, as Albrecht suggests, define our own > FL_POLLIN etc to avoid the problem, and have it set to match FL_READ, or > the local POLLIN (if it exists) or whatever. Oh, sorry, maybe I should have been more explicit: I meant that we should *use* FL_READ, FL_WRITE, and FL_EXCEPT directly in our code. There's no need to define FL_POLLIN etc.. AFAICT these constants are used only locally in our code (at least in Fl_win32.cxx) and not in any system calls. After a grep through src/*.c*: The same seems to apply to all other platforms, and I think that defining POLLIN etc. is redundant and should be avoided on all platforms, and that we should use FL_READ, FL_WRITE, and FL_EXCEPT directly on all platforms, as written before. [Subject to investigate by looking at the code, but I don't have the time to do this right now.] > Matching the "new" MS POLLIN value doesn't look right to me - it seems > to serve a different function and contains two bits, one for in-band and > one for out-of-band data... Yes, that's absolutely not necessary and would indeed be wrong. We might only need these constants if we use any MS-specific function call(s) that need it. And that's one more reason to avoid them in our internal code. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
