Discussion:
[Mingw-users] Missing pread, pwrite
Antonio Diaz Diaz
2017-03-22 20:00:36 UTC
Permalink
Hello,

This has been asked before, but never answered AFAICT.

Please, could pread/pwrite be implemented in MinGW?

The work is already done. Hannes Domani implemented his own versions of
the pread and pwrite functions in order to compile plzip on Windows
using MinGW. AFAIK, they have been working in plzip without problems for
more than 3 years.

The source is available in the file mingw.cc distributed with plzip at
http://download.savannah.gnu.org/releases/lzip/plzip/plzip-1.5-rc2.w32-w64.zip


Thanks,
Antonio.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Earnie
2017-03-22 20:19:16 UTC
Permalink
Post by Antonio Diaz Diaz
Hello,
This has been asked before, but never answered AFAICT.
Please, could pread/pwrite be implemented in MinGW?
The work is already done. Hannes Domani implemented his own versions of
the pread and pwrite functions in order to compile plzip on Windows
using MinGW. AFAIK, they have been working in plzip without problems for
more than 3 years.
The source is available in the file mingw.cc distributed with plzip at
http://download.savannah.gnu.org/releases/lzip/plzip/plzip-1.5-rc2.w32-w64.zip
What license was used for this package? I don't know that it is compatible.
--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Antonio Diaz Diaz
2017-03-23 12:28:42 UTC
Permalink
Post by Earnie
Post by Antonio Diaz Diaz
The source is available in the file mingw.cc distributed with plzip at
http://download.savannah.gnu.org/releases/lzip/plzip/plzip-1.5-rc2.w32-w64.zip
What license was used for this package? I don't know that it is compatible.
Plzip itself is GPLv2+[1], but the code of pread/pwrite was contributed
by Hannes Domani under any license required to compile plzip under MS
Windows (with MinGW compiler).

I admit that neither Hannes nor myself made this explicit in the Windows
binary package above. The code is simple enough (a forwarded call to
ReadFile/WriteFile) that I think it does not fall under copyright. But
if it is required, I'll ask Hannes to add a proper license notice.

[1] http://www.nongnu.org/lzip/plzip.html


Best regards,
Antonio.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-03-23 14:45:03 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Antonio Diaz Diaz
Post by Earnie
Post by Antonio Diaz Diaz
The source is available in the file mingw.cc distributed with
plzip at http://download.savannah.gnu.org/releases/lzip/plzip/plzip-1.5-rc2.w32-w64.zip
What license was used for this package? I don't know that it is compatible.
Plzip itself is GPLv2+[1], but the code of pread/pwrite was
contributed by Hannes Domani under any license required to compile
plzip under MS Windows (with MinGW compiler).
GPL is not compatible with MinGW.org supported code; we need to be able
to publish under a more permissive licence, such as MIT/Xorg.
Post by Antonio Diaz Diaz
I admit that neither Hannes nor myself made this explicit in the
Windows binary package above. The code is simple enough (a forwarded
call to ReadFile/WriteFile) that I think it does not fall under
copyright. But if it is required, I'll ask Hannes to add a proper
license notice.
Yes, please do. That would be helpful, (ideally MIT/Xorg format, as we
use in our own mingwrt sources, e.g. [1]), as would a formal feature
request, as per my earlier reply.

[1]: https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/mingwrt/mingwex/dlfcn.c

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

iQIcBAEBAgAGBQJY099vAAoJEMCtNsY0flo/3GsP+wchrtCGMYZLvcd12nC7gXos
Z0DjQTuzw0XPNXyyWmfUlZMVZ5bUrM7YYVoh96TKaDIE7U3niqPhTbroHdhYojsf
uw6zi/yX/jvCDCM2vGifC2ropPZuGmOyd35xu6MYQm7C60EfFtrSOAYMzILwwyHk
KThSCYs/A+mqF7w14eLO7xKdcDSwBWsbf/Faed1yOkYFqp2ye2sobXvWos2qdXFv
I8r88pitKEdgvZmOaKBAssWV9W7OrLomYiHJw+VdJPrILieXWPNWfFgrCQk+9eEY
m+ByYCupcxDO5D2y2UUX/q4CK9cTrjNjw2q8G2eGUsoeX4h+fPj2EDsTec2zV0qN
xZnOcykPmbUGUa2RRGMIPKa7M+ich1UPcq37zN4hVlHP/CvsHOyWVaGIOBjl13ev
f7sc6pgzbgJ4kAOlF8nQ+f5wxK6kWHGhw03PqAWF0qVTUnuqR5foLavw9umkM+EW
AuoPVr8WpV7q7knhU+kNuLoqpS8irly2K2XltauiItGcRPQoAzPTN+UQVh2I0dxn
mHCdTUiB+pMAt3NzVtHbi0skhuvNnAgJnw15fMX3Hp55njT+jAUxLkyDcjPOmzms
RZEiVPxkTWms4arXb2lwCHCay26fOyGeA9lwhsABfTNe5yEz61X5vB/cB0vQ5G4r
D2WiE3JIdekr2EuNK99X
=k7tP
-----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-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-03-23 14:29:09 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Antonio Diaz Diaz
This has been asked before, but never answered AFAICT.
Really? I could find only one reference:
https://sourceforge.net/p/mingw/mailman/mingw-users/thread/***@mega-nerd.com/

That, (asked in one of those hideous fora which core MinGW developers
detested, and mostly ignored), seeks advice on where to find pread()
and pwrite() for MinGW, (which at the time was nowhere, because they
don't exist within MSVCRT.DLL), or what alternatives might exist; it
Post by Antonio Diaz Diaz
Please, could pread/pwrite be implemented in MinGW?
There is one reply to that forum posting: it offers a naive, untested,
and fundamentally broken, (because of the race conditions it exposes),
implementation for pread(); there is no evidence of any associated
feature request, or of any actual code submission to MinGW.org, via
any other channel.

pread() and pwrite() are POSIX.1 functions, implemented only as XSI
options, prior to their incorporation into the base specification as
of POSIX.1-2008. Windows is not a POSIX conforming system, and MinGW
does not aim to make it so. At the time of that original posting, in
2005, when these functions were specified only as XSI options, it is
most unlikely that any request to support their incorporation into
MinGW would have been favourably considered by the lead developers
of that era; even today, when I have a more favourable attitude to
adoption of POSIX.1 features, without a formal feature request,
accompanied by a robust implementation, there may be no compelling
incentive for MinGW developers to pursue this.
Post by Antonio Diaz Diaz
The work is already done. Hannes Domani implemented his own
versions of the pread and pwrite functions in order to compile
plzip on Windows using MinGW. AFAIK, they have been working
in plzip without problems for more than 3 years.
An implementation deployed only within the context of one application
doesn't attest to its suitability for general adoption; in addition to
a formal feature request[1], with accompanying implementation, we would
require unit tests, (ideally implemented via autotest), to confirm its
conformance to POSIX.1-2008, its immunity to race conditions when used
in conjunction with open(), read(), and write() in distinct threads,
and its proper handling of associated error conditions.

[1] https://sourceforge.net/p/mingw/bugs/new/ (set Type = "Feature").

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

iQIcBAEBAgAGBQJY09u1AAoJEMCtNsY0flo/lYkQAMGLi1ATiqdrOzscZ3BODAQY
DLwYdahxVvt1tMA7K8dRHgB16BW6XXiYP7ze+m3fvdsySevzJVwfAAHTBKZ5lVG6
CrRj+2l9DB0Sx2wH8YqFGUzGEWvPnTbIRWXbGtfYknvCaON4IO39nzi9ETNXcbkB
FrrGgU02lXfzRkhdRFsUjMuExq7gdjDWM5hIth6jeuEo0ata1iFkMb2z61PAvOs+
XQ9KSufUA6kLYOjJL7CrUzoHu+ZaBCD8fNZUB6V9Ntt0i6jGmUl7xYFPSyhhVz91
YV5MytgOxG6KsR3Xbh6cUJiQhFmoVHwj3IOh/IbBGgbvBhIMZiTKHlWlmuyAVpeh
6DhYiarnUEM1gzXunGr9rcJLNuB3zxDjvtFW4XA3I3z3Nya/4uOeVrZNyNaY79Uf
XZSZTpMKJihoxEsXiddJ9+sOM6eAl192VjILj60rrggRp8o6dssuxYu8DttKbKRL
xPQP5Dn/u7rct35sYMoUqUbDXrrGtRUd4wuLzsxHTiPrRv5iZdewtFzqgP7rRokx
yxi0xiFDSBnlghQKm8XnXa/5/skxtfLRj2X73UsjWgoTuQbS08oQyYTl3LlH2Jhd
cBQaNShrYzs+h5ec/uAXdgrUWQCXb9aRydHO8+j4A2SC+KQaDJhNwYRJU00POmJZ
tAuDLTie1WpRQUwlVoMB
=Z/+T
-----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-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Antonio Diaz Diaz
2017-03-25 12:34:50 UTC
Permalink
its immunity to race conditions when used in conjunction with open(),
read(), and write() in distinct threads, and its proper handling of
associated error conditions.
First of all, thanks for the answer, and sorry for the noise. I do not
write Windows code. I was just forwarding a suggestion made in the
mailing list of my own project[1].

The implementation I sent is indeed inadequate for general use. I was
under the false impression that ReadFile/WriteFile were equivalent to
pread/pwrite, but I have just been told that they are not. They modify
the file position. They happen to work in plzip because the file is
opened just once and calls to pread/pwrite are never mixed with calls to
read/write.

[1] http://lists.nongnu.org/archive/html/lzip-bug/2016-05/msg00007.html


Thanks for all your good work,
Antonio.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-03-25 15:58:17 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Antonio Diaz Diaz
The implementation I sent is indeed inadequate for general use. I was
under the false impression that ReadFile/WriteFile were equivalent to
pread/pwrite, but I have just been told that they are not. They modify
the file position.
Thanks. Without even looking at the code, I feared as much. On that
basis, they would not be acceptable for incorporation into MinGW, and
with that in mind, (that I will not use it), I did take a peek at your
code; it turns out to be equivalent to, (omitting error handling):

ssize_t pread (int fd, void *buf, size_t count, __int64 offset)
{
_lseeki64 (fd, offset, SEEK_SET);
return read (fd, buf, count);
}

ssize_t pwrite (int fd, const void *buf, size_t count, __int64 offset)
{
_lseeki64 (fd, offset, SEEK_SET);
return write (fd, buf, count);
}

with no attempt whatsoever to either preserve, or to restore the file
pointer; (indeed, since these don't expose the ugliness of Microsoft's
lower level ReadFile() and WriteFile() APIs, I would favour such code
over that which you proposed).
Post by Antonio Diaz Diaz
They happen to work in plzip because the file is opened just once and
calls to pread/pwrite are never mixed with calls to read/write.
Sure, if you only ever use pread() and pwrite() to perform your data
I/O, you don't need to be concerned with any possible (bad) interactions
with read() and write(); OTOH, any worthwhile library implementation for
MinGW *would* need to show such concern. However, from an outsider's
perspective, even in the context of your plzip usage, I might tend to be
concerned by the total absence of any thread synchronization protocol,
in your proposed code.

All that said, and while I will not adopt your proposed implementation
as it stands, I do believe that an acceptable implementation could be
developed; it would be non-trivial, requiring creat(), open(), read(),
write(), dup(), dup2(), close(), and probably a few other existing calls
to be wrapped in some thread synchronization protocol, together with
similarly wrapped implementations for pread() and pwrite(). It would
(necessarily) be subject to usage restrictions, (unlike a truly POSIX
conforming implementation), and should be governed by an opt-in feature
test macro; as such, I don't know how much interest that would engender
among MinGW users, and I will not pursue it further, without a formal
feature request ticket on which its development may be discussed.

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

iQIcBAEBAgAGBQJY1pOZAAoJEMCtNsY0flo/dcgQALNHUMe9YZ5T7cfrr18UWw96
/0lNwuTxOZXJlNF+AQOomNsWM226ZblQD1VnSvKaruyCjsOC40jbScfV/GU+ocpX
XGjHOscKRGGRSCbxgUZZ7113L2T5dGgnVRyKo4de5TVz/ntWIwhX5XnOSdLqD9Rr
f0mvs31s8W5C2o46rWrH9hs8e6uozhstIm5/Rar8SMmKYtuVw0HaIJ0tVAzElZe2
oTJaqjtEEqAOGKIq9XorAnSd9+YZiOLmdtxHPyFz04M4lybDrOhQmX4TYhhewQwt
h1jG1Nf74OmbtIHeDYB4Ib4ZX/94S6FvrgngSyN7ly7z5S7rE3bSVYAYoGX7DQ06
mmFYvhK2ioenxiXc/hyrbTucfWGMocp6gzGuArfUdZqdQGzutbDjxiKzaljUTIiI
mB/ewpcbVnEcXtapFRyrc/4g5i3yjvHt0FitkT4OojG1ZqyD6f72pDUUMP7t75Ql
zMmTrCtLtMZOcIDOVmAW1wdrMIx3b6A2KGMwEExUa06relYWDWXWS44Xz9kiLJ9U
WbBmTc/afR91KtfOAUrD9YOsXedVYNbiMk5jeZDrTnuPzwzsMskUKjttEyDLlBkc
QOSz1L17MoLV05opn8606/ztIzBdLDnXUxajolTW2GF/VnBh0hkkMc+69/NPlncY
quZeEREqcy582Ltkm/Ri
=MXw/
-----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-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Eli Zaretskii
2017-03-25 16:26:59 UTC
Permalink
Date: Sat, 25 Mar 2017 15:58:17 +0000
Post by Antonio Diaz Diaz
The implementation I sent is indeed inadequate for general use. I was
under the false impression that ReadFile/WriteFile were equivalent to
pread/pwrite, but I have just been told that they are not. They modify
the file position.
Thanks. Without even looking at the code, I feared as much. On that
basis, they would not be acceptable for incorporation into MinGW, and
with that in mind, (that I will not use it), I did take a peek at your
ssize_t pread (int fd, void *buf, size_t count, __int64 offset)
{
_lseeki64 (fd, offset, SEEK_SET);
return read (fd, buf, count);
}
ssize_t pwrite (int fd, const void *buf, size_t count, __int64 offset)
{
_lseeki64 (fd, offset, SEEK_SET);
return write (fd, buf, count);
}
with no attempt whatsoever to either preserve, or to restore the file
pointer; (indeed, since these don't expose the ugliness of Microsoft's
lower level ReadFile() and WriteFile() APIs, I would favour such code
over that which you proposed).
Why is that better than the original code proposal? That one at least
didn't suffer from the race condition between the lseek and the
following read/write call.

And where is the evidence that ReadFile/WriteFile indeed modify the
file position? The MSDN docs says that the offset is updated, but
says nothing about the file pointer.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Keith Marshall
2017-03-25 19:12:19 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Eli Zaretskii
From: Keith Marshall
Date: Sat, 25 Mar 2017 15:58:17 +0000
Post by Antonio Diaz Diaz
The implementation I sent is indeed inadequate for general use. I was
under the false impression that ReadFile/WriteFile were equivalent to
pread/pwrite, but I have just been told that they are not. They modify
the file position.
Thanks. Without even looking at the code, I feared as much. On that
basis, they would not be acceptable for incorporation into MinGW, and
with that in mind, (that I will not use it), I did take a peek at your
ssize_t pread (int fd, void *buf, size_t count, __int64 offset)
{
_lseeki64 (fd, offset, SEEK_SET);
return read (fd, buf, count);
}
ssize_t pwrite (int fd, const void *buf, size_t count, __int64 offset)
{
_lseeki64 (fd, offset, SEEK_SET);
return write (fd, buf, count);
}
with no attempt whatsoever to either preserve, or to restore the file
pointer; (indeed, since these don't expose the ugliness of Microsoft's
lower level ReadFile() and WriteFile() APIs, I would favour such code
over that which you proposed).
Why is that better than the original code proposal?
It is cleaner. It is better aligned with the standard it sets out to
implement. It better expresses what it actually does. It passes the
offset argument as-is, avoiding the gross ugliness of splitting into
two parts, to assign it to two separate fields within an OVERLAPPED
structure argument.
Post by Eli Zaretskii
That one at least didn't suffer from the race condition between the
lseek and the following read/write call.
Really? How can we possibly know, without seeing Microsoft's kernel
source? MSDN warns that ReadFile() isn't thread safe, advising that
multi-threaded applications should protect I/O operations, which use
it, with mutex, or critical section synchronization protocols. Race
potential is present anyway, and just as likely between adjustment
of the file pointer and commencement of data transfer, as at any
other time within the scope of the ReadFile() call.

The foregoing applies equally to WriteFile().
Post by Eli Zaretskii
And where is the evidence that ReadFile/WriteFile indeed modify the
file position? The MSDN docs says that the offset is updated, but
says nothing about the file pointer.
It is trivially easy to demonstrate. If I link this:

#define _XOPEN_SOURCE 700

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>

int global_fd;

const char *letters = "abcdefghijklmnopqrstuvwxyz";

int main()
{
char tmpname[] = "preadXXXXXX";

if( (global_fd = mkstemp( tmpname )) >= 0 )
{
ssize_t maxlen = strlen( letters );
write( global_fd, letters, maxlen );
close( global_fd );

if( (global_fd = open( tmpname, O_RDONLY )) >= 0 )
{
char buf[4];
ssize_t max_offset = maxlen - sizeof( buf );

pread( global_fd, buf, sizeof( buf ), 3 );
printf( "pread: %.4s\n", buf );

while( lseek( global_fd, 0, SEEK_CUR ) < max_offset )
{
read( global_fd, buf, sizeof( buf ) );
printf( "read: %.4s\n", buf );
}
close( global_fd );
}
}
remove( tmpname );
return 0;
}

with the OP's pread() implementation, and run it; I see:

$ WINEPATH=`pwd`/mingwrt ./a.exe ; rstty
pread: defg
read: hijk
read: lmno
read: pqrs
read: tuvw

(and identically the same when run for real, in a WinXP VM). If the
file pointer wasn't moved by the pread() call, (as it should not be),
the correct output would be:

$ WINEPATH=`pwd`/mingwrt ./a.exe ; rstty
pread: defg
read: abcd
read: efgh
read: ijkl
read: mnop
read: qrst
read: uvwx

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

iQIcBAEBAgAGBQJY1sETAAoJEMCtNsY0flo/negP/ipw1WyKVtO4+FYitwXRkZzY
LZvVx0SC+z1nb386sDZhwj0v4Xi6uVEX7zvYv1DvEIvFn9hB2y6k2DHTaMz7k678
n8e/66iuYtIhwu7wlMdS0xBlw2GP9PDvg6PIaHGL9Zf2zrCrWFZzZTmdXdcOlci0
dLwdieYvWjItJkyRVIS4GNpmE9eBvt0uDEUTHGnmYLvefOuSKsdgcvCmYE1GAHd7
jH3GHSJ9SaZWq2E3dBeAmSqFS08QKiUZb/NJ78puUZ9w58oLPCeLhmqeDMnjINR4
adN+kJcNz8U3nk3MD2vsOPu/mnb3YPQ6vlsrUuAhPH+wQAjtdI7gQUsaUikBOqq/
342jF2UTiw5Po139KjShFI15/IUpZHa5td6GB2Umj/gqGq4qKucUpCEvdbJyOgpi
fCD2lif4rNpM06S9doLd58uF+k29Mq2Lo7qUrd0RtAMILnYdHCfSWFf/R2eRjtIR
R2/Xv9tm2C1gO9wnr1tFnvf8oMFuSOosMBm6yA+svwYoLlE4G7A2nDfyOmHT9H89
nBqjVTKJZXM684W6afoG7ndfKpsW0twNux62AUO615uggLbI04ITkZJOEuo0pdlY
Gvj2Z4Wt+ELJfOhbDON/B2qFdj9HuYRcblJZAVYfhczGtHtZSnwOmrhlOmHSAxux
Z7k+1chMW6iMrEeY4L3Z
=uF81
-----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-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe
Loading...