|
|
@ManoloFLTK @michaelbaeuerle Just my 2 ct to the proposed patch:
-
OK in general, but since lround() is currently used only on macOS (Cocoa related stuff) and in src/Fl_Anim_GIF_Image.cxx we could as well make this locally in Fl_Anim_GIF_Image.cxx , particularly because the result of lround() is always cast to another type. It looks like we could use round() with a proper cast instead of lround() in the first place. @wcout What do you think (as the author of Fl_Anim_GIF_Image ?).
-
The macOS usage doesn't need to be changed anyway because all supported versions provide lround().
-
The patch itself (if used as proposed) should probably be guarded by a POSIX version check to avoid multiple definitions if newer AIX versions provide lround() - maybe only to prevent using the own inline definition rather than the system provided one. @michaelbaeuerle ?
FYI: I tested a similar patch on Linux with and w/o the keyword inline . Using inline prevents a compilation warning on my Linux system (multiple definition of lround'otherwise). However, I'm not sure what happens if lround()has been defined by the included math.hheader and subsequently overridden by the inline` definition. I assume it would use the inline version and finally call round().
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/942/2016510261@github.com>
[ Direct Link to Message ] | |
|
| |