Web lists-archives.com

Re: [Mingw-users] Errors in _finddata64_t and _wfinddata64_t naming




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

On 24/10/16 19:29, Keith Marshall wrote:
> On 24/10/16 16:00, Earnie wrote:
>> On 10/22/2016 4:47 PM, Keith Marshall wrote:
>>> Historically, the __finddata64_t and __wfinddata64_t type
>>> names are correct, and the _finddata64_t and _wfinddata64_t
>>> forms are wrong, but perhaps we should just accept that
>>> Microsoft are utterly incompetent, when it comes to documenting
>>> their products, and, on account of the gross inconsistency on
>>> MSDN, declare *both* forms as being "correct"?
> 
>> Yes, I think so.
> 
> Okay, I'll proceed on that basis, (I'll duplicate the definitions
> for __finddata64_t and __wfinddata64_t, with the alternative names,
> each with only one initial underscore).

I think the attached patch will do the trick.  Note that we must
#define the alternative names, otherwise we introduce "incompatible
data type" warnings, (which become errors, in 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)

iQIcBAEBAgAGBQJYDou9AAoJEMCtNsY0flo/4TwQAIH3Blpf2aWg4Kl8x5tyIUD6
KRtJqi7gNWFlaHVHbuTyBvGyjCiZchEZ6l1LA25jGkLn5eYvg87uExCyFyTkjcyx
ROG26yyzdMDpRqSWBnOOKER7tD93MTYo3E4oux+jj68bYQdTJFLiP1J0ZKK0/h0B
YkuxumAfkjUWm176QmHvZdE2kSFkQfDvnLdwXShNpSMh+aMUFp7PEU4T3ObIBOKf
rpKsuPYe2QYqL9Qclx6DaYXjgdGjLe0PryCsB8SvraaSndZW0ZdPq4yQNuK84vqi
IFxnJ48s8Gq5VrrBE8YU3mZW37ai+4sScrttDaAR/2XdjSzS4NQ2fZ8SoaZS1vmE
Ut6zAfVKPuV8ee9/xV3b/7hjuk4Zby9fE9D5nuY5tph1CAGvzkzX2tF7zAP9dnzY
iE+6Vpeol/+1hptQelh/QaAOayVeEwsJq/RczCHCXtH62JwEiVnQbnDIsUugxLiP
GxzH89257v9ycYHF6H1IXq6qxLimWWMeyyUbTi/m/FHFGK0Z+FR3dqwlkIK//XVr
QmNOVaUDcGwWIeuZazETpfT22jGUtZEiKiO+6JeahfqEKVMySv4BnUHeJp4Mov5J
6Jy3r1tuUbkwUbfvprBrWY08fm47nm0gx9BwIZJY6t9n9P4B8pt/DGjQU9A1ZHB/
FC6IzFZlwuGbf81vj4xq
=dywN
-----END PGP SIGNATURE-----
# HG changeset patch
# Parent f69a207c664e2f66f413f9dd78d035be63bdead8
Support MSDN finddata_t naming inconsistencies.

diff --git a/mingwrt/include/io.h b/mingwrt/include/io.h
--- a/mingwrt/include/io.h
+++ b/mingwrt/include/io.h
@@ -219,10 +219,16 @@ int _findnexti64 (intptr_t, struct _find
  * all 32-bit variant added at this point in the evolution of the
  * API; had there been, it would have been identically equivalent
  * to the original generic _findfirst()/_findnext() implementation).
  */
 struct __finddata64_t __struct_finddata_t (__time64_t, __int64);
+/*
+ * Some MSDN documents, (particularly more recent documents), may
+ * inconsistently refer to this structural type by the anomalous
+ * name of _finddata64_t; support this anomaly.
+ */
+#define _finddata64_t  __finddata64_t
 
 _CRTIMP __cdecl __MINGW_NOTHROW
 intptr_t _findfirst64 (const char *, struct __finddata64_t *);
 
 _CRTIMP __cdecl __MINGW_NOTHROW
@@ -358,10 +364,17 @@ int _wfindnexti64 (intptr_t, struct _wfi
 #if _WIN32_WINNT >= _WIN32_WINNT_WIN2K || __MSVCRT_VERSION__ >= __MSVCR61_DLL
 /* Win2K also added an all-64-bit variant of the _wfinddata API to
  * MSVCRT.DLL, after it originally appeared in MSVCR61.DLL.
  */
 struct __wfinddata64_t __struct_finddata_t (__time64_t, __int64);
+/*
+ * As in the case of the __finddata64_t structure, some MSDN
+ * documents, (particularly more recent documents), may refer
+ * to __wfinddata64_t by the inconsistently anomalous name of
+ * _wfinddata64_t; support this anomaly.
+ */
+#define _wfinddata64_t  __wfinddata64_t
 
 _CRTIMP __cdecl __MINGW_NOTHROW
 intptr_t _wfindfirst64 (const wchar_t *, struct __wfinddata64_t *);
 
 _CRTIMP __cdecl __MINGW_NOTHROW
@@ -370,13 +383,24 @@ int _wfindnext64 (intptr_t, struct __wfi
 #if __MSVCRT_VERSION__ >= __MSVCR80_DLL
 /* MSVCR80.DLL introduced a further three variants, which remain
  * exclusive to it and its later derivatives; none of these are
  * available in any version of MSVCRT.DLL.
  */
-struct __wfinddata32_t __struct_finddata_t (__time32_t, __int32);
+struct _wfinddata32_t    __struct_finddata_t (__time32_t, __int32);
 struct _wfinddata32i64_t __struct_finddata_t (__time32_t, __int64);
 struct _wfinddata64i32_t __struct_finddata_t (__time64_t, __int32);
+/*
+ * As in the __finddata64_t vs. _finddata64_t, and __wfinddata64_t
+ * vs. _wfinddata64_t anomalous cases, there is at least one historic
+ * MSDN reference to a __wfinddata32_t structural type, in a context
+ * where _wfinddata32_t may be expected.  In this case, it appears
+ * that __wfinddata32_t is the anomaly, and that it may be peculiar
+ * to the VS-2005 documentation; nevertheless, the corresponding
+ * definition is provided here, for the possible convenience of
+ * any user who may depend on it, (but please avoid it).
+ */
+#define __wfinddata32_t  _wfinddata32_t
 
 _CRTIMP __cdecl __MINGW_NOTHROW
 intptr_t _wfindfirst32 (const wchar_t *, struct __wfinddata32_t *);
 
 _CRTIMP __cdecl __MINGW_NOTHROW
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

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-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe