Am Samstag, den 20.09.2008, 10:50 +0200 schrieb Michael Karcher:
Looks like we need to compile with -fno-builtin-sscanf, because gcc knows the implementation of glibc's sscanf,
OK, I looked further into it. On Linux, we don't get the warning, because gcc is called with the sledgehammer option "-fno-builtin" for msvcrt related stuff (which includes *all* -fno-builtin-* options, so also -fno-builtin-sscanf) if gcc's builtin prototype for the wchar ctype function conflicts with "int iswlower(unsigned short);". Probably on your system, your C library does not have these functions or your gcc is older than 4.0, so there are no builtin prototypes for the wchar stuff.
There are some ways to fix it: a) Detect whether gcc recognizes scanf as builtin function, and enable -fno-builtin in that case too. This will trigger on gcc version 3.3 and up. b) Always pass -fno-builtin to msvcrt related stuff when compiling with gcc, i.e. drop the wchar test. c) Make the -fno-builtin option more specific. i.e. if wchar stuff conflicts with msvcrt, enable -fno-builtin-iswalnum -fno-builtin-iswalpha -fno-builtin-iswascii -fno-builtin-iswcntrl -fno-builtin-iswdigit -fno-builtin-iswgraph -fno-builtin-iswlower -fno-builtin-iswprint -fno-builtin_iswpunct -fno-builtin-iswspace -fno-builtin-iswupper -fno-builtin-iswxdigit -fno-builtin-towlower -fno-builtin-towupper and if scanf is detected, enable -fno-builtin-fscanf -fno-builtin-scanf -fno-builtin-sscanf The upside is that we don't lose gcc's checking of other standard C functions, while the downside is that the gcc command line in msvcrt related modules gets awfully long. These modules are: dlls/msvcrtd/tests dlls/msvcrtd dlls/msvcrt/tests dlls/crtdll (Just grep Makefile.in for @BUILTINCFLAG@) While the specific -fno-builtin-foo optins have been introduced in gcc 3.1, we do not need to check whether gcc is new enough, as these old versions of gcc have neither wchar nor sscanf functions built in.
If wine-devel agrees to one approach, I am happy to submit a patch that implements this approach. I personally prefer a crossover between approach b and c.
Approach a is out, because on recent versions of gcc, it is essentially approach b, but unnecessarily complicating the configure script. Also it tends to hide problems, just as it happened here. gcc has added a sanity check for sscanf parameters (which is a good thing, IMHO), but we never noticed it, because it got suppressed because of configure finding wchar builtins on the platform most Wine developers work on. With this approach, changing the platform might change gcc's behaviour on sscanf without anyone expecting it.
Approach b is correct in the sense that the MS C library is not the platform C library, so gcc better does not assume anything about it, but that also might incur performance penalties, as things like memcpy with small constant size will never get inlined. Probably b really is what the wine project needs in the tests of msvcrt, as the goal is to test msvcrt and not gcc's inline code. For the tests, performance penalties do not matter.
On the other hand, for the implementation side (msvcrtd and crtdll), option c seems attractive to me, because it just disables the stuff we need disabled but allows gcc to take full advantage about knowing the C standard on functions where msvcrt is not incompatible. A problem with option C is, that it is playing a cat-and-mouse game with the gcc developers: As soon as they add some more checks to calling standard library functions that are incompatible with Microsofts extensions, we start to get warnings again.
Regards, Michael Karcher