Re: Errors in the Win32 bindings

["Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>]

"Martin Dowie" <martin.dowie@baesystems.com> wrote in message
news:3ef8340b$2@baen1673807.greenlnk.net...
> Who should these errors be reported to?
>
> e.g. function utime takes an access parameter which
> prohibits passing a 'NULL' although this is a valid
> value for this routine.

I found a similar error in the Win32.Winsock package. The specification for
the "select" function (renamed "c_select" to avoid the reserved word) is

    function c_select(
                nfds     : Win32.INT;
                readfds  : access FD_SET;
                writefds : access FD_SET;
                exceptfds: access FD_SET;
                timeout  : ac_TIMEVAL_t)
               return Win32.INT;                            -- winsock.h:741

which prohibits using null for readfds, writefds, and exceptfds, in spite of
the fact that this is a common method of passing empty sets to "select".
Given that Win32.Winsock already defines the following access type

    type PFD_SET is access all FD_SET;                      -- winsock.h:846

we could fix this problem by using this access type to declare readfds,
writefds, and exceptfds, e.g.

    function c_select(
                nfds     : Win32.INT;
                readfds  : PFD_SET;
                writefds : PFD_SET;
                exceptfds: PFD_SET;
                timeout  : ac_TIMEVAL_t)
               return Win32.INT;                            -- winsock.h:741

With this declaration, you can use any combination of nulls and access to
actual FD_SET values in a call to "c_select".

Also, the package specification for Win32.Winsock is missing a declaration
for the FD_ZERO procedure, which should be there as an inlined subprogram.
Curiously, a body for FD_ZERO can be found in the Win32.Winsock package
body.

What is frustrating is that these problems are ridiculously easy to fix, if
only we knew who is responsible for maintaining the Win32 packages. I raised
this issue in this NG several months ago. None of the responses answered the
question of who owns Win32.

If no one is currently maintaining Win32, should a group of dedicated Ada
engineers take it over, perhaps making it a sourceforge project?