"MacArthur, Ian (Selex ES, UK)" wrote: > Michael Baeuerle wrote: > > "MacArthur, Ian (Selex ES, UK)" wrote: > > > > > > Uploaded as STR #2931. > > > > Thanks. Somebody with a Windows machine should verify the code. > > Yes, I did; at least on WinXP. > Built and ran fine.
Good. I only added the 'const's to the parameters and don't touch the code itself. > I guess the only issue would be if someone was "secretly" > using fl_scandir() directly in their own code and got caught > out by the prototype being made more strict, but that > might count as a self-inflicted injury? IMHO yes. The compare functions are intended to compare and only to compare. If somebody "expect" them to modify the objects or provide its own sort function that do such nasty things ... I think this can really be seen as abuse. In reality this should very rarely happen because 'fl_scandir()' is intended to be used with the 'fl_*sort()' function family defined by FLTK (which I have modified to matching constant parameters too). As said above, the 'fl_*sort()' functions now have constant parameters too. But it should still be possible to call them with non-constant objects with the correct result (the objects are simply not changed as before). > Other than that, I guess we need to verify it on a few more > systems - e.g. OSX before and after the 10.8 transition where > they made their scandir() prototype more POSIX compliant. > (I only have access to 10.6 these days...) Yes, I have merged all cases that in fact had the same API together. At first I was confused about some lines use 'struct dirent' and other lines use 'dirent' (and from a C programmers view I nowhere found a typedef for 'dirent'). But 'filename_list.cxx' contains C++, and C++ implicitly adds the 'struct' keyword if it is missing: http://www.cplusplus.com/doc/tutorial/structures/ This makes some of the former different looking lines compile to the same code. > I guess most Linuxes will be fine, though have not checked; > what systems have you tested on? Currently I have tested the following systems: ---------------------------------------------------------------------- Windows: - None yet Systems with no usable native 'scandir()': - SunOS 5.7 (64Bit, big endian) Systems with a native POSIX.1-2008 compliant 'scandir()': - None yet OSF/DU/Tru64/IRIX: - None yet AIX: - None yet Systems with native 'scandir()', but not a POSIX.1-2008 compliant one (plus it match to none of the explicitly handled cases above): - GNU/Linux with glibc 2.8 (32Bit, little endian) - NetBSD 5.1 (32Bit, little endian) ---------------------------------------------------------------------- Please add yours too, so that we get a complete single list. AIX and HP-UX again with the final code will follow from me ... > Also, maybe need to get you to assign the copyright of > scandir_posix.c to the fltk project? Not sure how that is > handled, actually... As an example: 'Fl_PNG_Image.cxx' contains copyrights too. I have applied the FLTK license to the new code, this means everybody is allowed to do with it the same things as with the rest of the library (at least modify, redistribute and statically link). So I think it is no problem (IANAL). In any case: I have written this code for the FLTK project to resolve a copyright/license problem, so we definitely will find a way that the FLTK project get a problem solved and not a new problem ;-) Regards, Micha _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
