On 1 Jan 2010, at 20:32, Albrecht Schlosser wrote: > imacarthur wrote: > >> Just tested this on Vista with mingw, and it fails exactly as >> Greg's VS >> example fails (because mingw mainly just wraps the native system >> libs in >> general.) > > That's strange. I can't confirm this with WinXP and the cygwin/mingw > compiler (neither in cygwin nor in mingw (-mno-cygwin) compilation > mode.
I acknowledge that we have differing views on this, but I do not believe that "cygwin -mno-cygwin" is actually the same thing as mingw. In particular, I think that the -mno-cygwin option mainly turns off the use of the "posix emulation" features of cygwin, but I do not think it stops the use of cygwin's own built in libc etc. (IIRC, at one point in the past, cygwin's libc etc were derived from newlib... they may have moved to something else since, of course.) The mingw build provides no libc etc., it simply wraps the MS runtime already on the system: and that, I suspect, is why we see differing results with this test. My test with mingw looks exactly like Greg's test with MS VS, presumably because the underlying lib being used is the same, but the cygwin tests give better results because the cygwin builds use a proper, non-broken, libc etc... > Then I tried this: > > #ifdef _WIN32 > extern "C" int fl_snprintf(char *, size_t, const char *, ...); > #define snprintf fl_snprintf > #endif /*MICROSOFT*/ > > instead of trying to use _snprintf_s, because we do already have > this in src/vsnprintf.c :-) Oh! Now that might be a good way out of this... > > Compiling with fltk-config: > > $ ../fltk-config --compile snprintf.cxx && ./snprintf > g++ -I.. -I../png -I../zlib -I../jpeg -mwindows -DWIN32 -DUSE_OPENGL32 > -mno-cygwin -I/usr/local/hs/include -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -o 'snprintf' 'snprintf.cxx' -mwindows -mno- > cygwin > -L/usr/local/hs/lib ../lib/libfltk.a -ldl -lole32 -luuid -lcomctl32 > RET=6, SS='123456': TEST RESULT: OK > RET=7, SS='1234567': TEST RESULT: OK > RET=8, SS='1234567': TEST RESULT: OK > RET=9, SS='1234567': TEST RESULT: OK > RET=10, SS='1234567': TEST RESULT: OK > > > Looking in the code, it appears that fl_snprintf calls vsnprintf, and > that seems to work (I have HAVE_VSNPRINTF and HAVE_SNPRINTF defined > in config.h, otherwise these calls would be redefined to call their > fl_* replacements). I'll need to try this in a mingw build too - time permitting! - but this looks like a solution that will work in a general way across all the win32 variants. Wonder if it flies for Greg with MS VS, too? _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
