msvcrt: scanf fix a typo

[Michael Karcher]

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