RFC: Make w32api headers (effectively) self-contained

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFC: Make w32api headers (effectively) self-contained

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guys,

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'd like to start adding #include statements, as required, to make each
system header (effectively) self contained, and implement unit tests to
verify them.  Any reasons why I shouldn't do this?

- --
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)

iQIcBAEBAgAGBQJYTypIAAoJEMCtNsY0flo/a1gQAKYnRpZs0swYs84/mOXbNXWI
wogHlm6Cm6MdW4/k3Nx7mvrBCCFuS6pJrluL/qKKF4hdquUpFPjtwnrD6DSaycc1
C4TL7Dsm+nibzYa989y185BZK/JwEkChhoJhnxFG8woYLt41jVV2nSADgdJTgnv4
zvJKHjXbO7Tcp3BZAkhAi4jCwzxf7BSaTBUWhoQh6gL/Lv1M6WeooQID0oDIJxwG
dr8bt+0T8OakgR+SHkzkfnjj4ki19DqtHIOi+AtQ6DNDzlmyel74Q8wWSv2XtYdm
PFas3DjeE5yTgGvgpd+i/CGmfu9NPlTqmB7yYZ7LqY/1A7GqFtaFkutgFxYzYqTN
H66OA92QxYdHjneqVXDpRB3eoZMtWWDSYrmeMti+LGb2RdXloVZ4iFd23yXuEo/h
v93dagGGiPwPSe47/gxKovudXiLJzucWxqSQ5OEkxrfII9lgDcnAzw54wbRi4Wi3
+6GnacSC+53M4Xq7ccCw4wkMpzit3zRvh1FWw/ivu67Z0N5TGszjmx8tJrOZE48M
9IORR82aolBHKmOptf/8TeVQ8UNrZ/W29gwCrKEB0qOS3nago0CScjVsZCUDZVV6
gVODeVoMBvbbSgjXHU4inXT5jOjNIsxp8TIftoFpVwlTUMOHQ8TrDID9ydJsOTn8
Qzytalkbzkt+z7a9Du3E
=AA2q
-----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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Earnie Boyd
On 12/12/2016 5:52 PM, Keith Marshall wrote:
>
> I'd like to start adding #include statements, as required, to make each
> system header (effectively) self contained, and implement unit tests to
> verify them.  Any reasons why I shouldn't do this?

It's a horrid mess, feel free to simplify, it can only make maintenance
easier.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Keith Marshall-3
In reply to this post by Keith Marshall-3
-----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
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Earnie Boyd


On 2/24/2017 10:10 AM, Keith Marshall wrote:

> 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.
>

Great, thanks Keith.  Something that we've needed since day one.

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...