Re: RFC: Make w32api headers (effectively) self-contained

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/12/16 22:52, Keith Marshall wrote:
> I've started playing with autotest, to implement unit tests for mingwrt
> and w32api; (so far, I've implemented several tests for mingwrt, among
> them a test group to verify self-containment of system headers).  This
> is fine for mingwrt, but right now, if I invoke (say):
> 
>   $ echo '#include <winuser.h>' | mingw32-gcc -c -xc - -o /dev/null
> 
> I see a swathe of error messages, relating to undefined (custom) data
> types; (winuser.h has inherent prerequisite dependencies on windef.h,
> stdarg.h, and by default wingdi.h).  I don't know how Microsoft handle
> this, but IMO it is just dreadfully poor software engineering; users
> should not need to be concerned by such interdependencies among system
> headers.

I've now added some preliminary unit tests into the repository, for both 
mingwrt and w32api; in both cases, header integrity and self-containment 
is tested, for each header file in isolation, and for all together.  For 
mingwrt, I've also added a set of printf() tests, and tests for some of 
the mathematical functions.

In the case of mingwrt, on the basis of the tests implemented so far, we 
look in pretty good shape; interestingly, the failures I am seeing all 
result from improper error reporting at mathematical domain boundaries, 
in MSVCRT.DLL function implementations, (where I'm taking the logically 
correct mathematical behaviour prescribed by POSIX.1-2008 as indicative 
of "correct" behaviour).  It may also be of interest that, if I run the 
test suite under wine, I see approximately twice as many failures, from 
the same functions, indicating that wine's MSVCRT.DLL implementations 
exhibit even less correct behaviour that the Microsoft originals.

In the case of w32api, I've added tests only for the integrity of the 
headers in the top level include directory.  Right now, I'm seeing a 
failure rate of around 60%, usually because headers are dependent on 
<windef.h>, <winbase.h>, <winuser.h>, or <wingdi.h>, but don't bother 
to ensure that the dependency is satisfied when included in isolation.  
I have a queue of about 130 patches, to resolve the stand-alone cases.  
However, even with the stand-alone cases resolved, the composite case 
will still fail, due to conflicts:

1) <ole.h> is incompatible with <ole2.h>; since <ole2.h> is often 
   included by default, this renders <ole.h> mostly useless, but 
   should we add a warning to this effect?

2) <rassapi.h> and <mprapi.h> declare some common content, but the 
   declarations (particularly of structures) are incompatible; GCC 
   will report errors, when the incompatible declarations are read,
   so maybe just suppress the second declaration, on condition of 
   an __IN_W32API_TESTSUITE__ guard macro?

3) <vfw.h> and <aviriff.h> declare some common content; as defined,
   this introduces conflicts, although all definitions appear to be
   compatible; this begs refactoring of the code.

I'd like to get wsl-5.0 (as mingwrt-5.0 and w32api-5.0) out as quickly 
as possible, so I'm reluctant to delay it, while I work through this 
patch queue.  Even as it now stands, we're in no worse state than we 
have been, with previous releases (perhaps) since Anders Norlander's 
original w32api incarnation ... except that we now have a test suite 
to raise visibility of the problems.  Thus, in the absence of any 
objection, I'd like to release wsl-5.0 at the end of February, and 
work through the patches for wsl-5.0.1.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYsEzpAAoJEMCtNsY0flo/5dMP/3gdegKCJiMvSASoQxFE/ADr
itWQCEvXnwUf6gXD+zn8xxYvgMa3nkdzun9SGM6rXYniYb/2KmzAIBxcYqwf6x8Q
wkoWJpIENLKVHM66SodR8yzBZWo4BNUCaYZo50CW/W2xu+FFVX9RkYSKMn3jEqd4
D7zhMgYGeIqeQh2V1W2cA8jkjlRnY4fkjm+2rroj7hlzuDNsFGQXrhs44cFaj5he
aFa2usiUd0gTjJj/TRujNt6XMlrNb9f1jUVvRCkxI/Nz5+eNh22TS+y+YU0N052x
xbTuLjHUKqg58v08ESYddIMz+UOBENeb8JEdQeM1+TYLnELJ3xZUxFcbvc8Cv5NA
nvHHGSUvknsts6hzIChCPsSHALUxldeyzvm27Am684q6SX1Rsoew0ilM/FyKvunw
ZdVtWDxz+tNuclPONiCFWgtulLkM5WwE6v8Vh/Sp6asX9gCH6UTb/bqgEN9lSU1b
wpTgcv9COn+RXR31hpzIulTb70KmajQWIuuv1OF/3fXDVCpYup+msGGi/3ma1nLk
lGU15mdQhSoCqLolATbEJnwbzpNWWmO+c5JpXwHQZLb2/twnqHfI5rbX3cTTrMc0
qLEoe8M8WY0K92kh2kclkOl17Ft65IwPZjqZgRuAxdws+RESVQ7miJ2C+qYx86U9
hOVD1PA0xXv35gb74cIE
=oT8Y
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot