Quantcast

Errors in _finddata64_t and _wfinddata64_t naming

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

Errors in _finddata64_t and _wfinddata64_t naming

Romain Garbi
Hello guys !

I just found that mingw has wrong names for _wfinddata64_t and
_finddata64_t (which are declared as __wfinddata64_t and __finddata_t in
spite of what msdn reads here :
https://msdn.microsoft.com/en-us/library/zyzxfzac.aspx ). Is there a
particular reason for this ?

Thanks in advance,
Romain

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Errors in _finddata64_t and _wfinddata64_t naming

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

On 22/10/16 18:02, Romain Garbi wrote:
> Hello guys !
>
> I just found that mingw has wrong names ...

Who says they are wrong?

> for _wfinddata64_t and _finddata64_t (which are declared as
> __wfinddata64_t and __finddata_t in spite of what msdn reads here
> : https://msdn.microsoft.com/en-us/library/zyzxfzac.aspx ).

And that particular reference is inconsistent with several other
references, on MSDN, to this pair of data types; e.g.:
https://msdn.microsoft.com/en-us/library/kda16keh.aspx
https://msdn.microsoft.com/en-us/library/zyzxfzac%28v=vs.80%29.aspx

> Is there a particular reason for this ?

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"?

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

iQIcBAEBAgAGBQJYC9BWAAoJEMCtNsY0flo/shQP/0RPqLTflODzSVi34+zkABdI
s7ckItUMbjyaJszKsfpA+Tbkaky44cv53/H8AnivB3P7LI0ubBhb3C0SPGBf/oU5
6YxGFL3T1y3nFSXmAfOGWdoYikCFl+r2AzJoIobGVBN7K5HalrwworYGNTUlvy94
PTYyXE7IGRQw+n0ko0RwdyhHwFPLY0OqO7PaBSLT+MT0WEhtN7AMyg44jJOjiucj
1QcDcytEVLW17JNRE6Kt3znC1tioKEM+z5+pPtzuNVpAFlSpyu7OyuM940gM1Peb
8HzYUcpUgZ85JgEwMBUE3bCfredB3kfN6rh3gAqq2L0iSWYnE0ihZXTzSN1LaNtS
DD9YCncslzBkPz96QCw243PhtQhxt6ZhX/zSyJ1M+arhXv6Bl3WG+NtbJ5C7Va42
PypfOKUpd/Pt0V+H4PmxUfKb5Kn422Kf053cJKNBSaXR+uutFn9h/NN5ZHZ/TEmv
DSV+DZcbGe5HYLExwBNOyn81ID+xhb5y1hh+tfEL+vcSTCPPnzVFAjYN/j00D5Qj
0RQy4C95I+ly4sL6OWqIl10Yv3vRxxcAoEnI9pjabruIzTVYy4DcR+yUeF0jwo2K
07sPMGGZiqFzHaFrCWKpA8SXTkyJbuulZVXC3FuiyO8xgywHzkQn5imPjyipWgBG
DIgVmo7DWwpD9dOjFu3P
=P/Fd
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Errors in _finddata64_t and _wfinddata64_t naming

Earnie Boyd
On 10/22/2016 4:47 PM, Keith Marshall wrote:

> On 22/10/16 18:02, Romain Garbi wrote:
>> Hello guys !
>
>> I just found that mingw has wrong names ...
>
> Who says they are wrong?
>
>> for _wfinddata64_t and _finddata64_t (which are declared as
>> __wfinddata64_t and __finddata_t in spite of what msdn reads here
>> : https://msdn.microsoft.com/en-us/library/zyzxfzac.aspx ).
>
> And that particular reference is inconsistent with several other
> references, on MSDN, to this pair of data types; e.g.:
> https://msdn.microsoft.com/en-us/library/kda16keh.aspx
> https://msdn.microsoft.com/en-us/library/zyzxfzac%28v=vs.80%29.aspx
>

Sorry, Keith, I see these references with a single _ and not the __
underscore.  Well actually looking closely I see a reference to both.


intptr_t _findfirst(
   const char *filespec,
   struct _finddata_t *fileinfo
);
intptr_t _findfirst32(
   const char *filespec,
   struct _finddata32_t *fileinfo
);
intptr_t _findfirst64(
   const char *filespec,
   struct __finddata64_t *fileinfo
);
intptr_t _findfirsti64(
   const char *filespec,
   struct _finddatai64_t *fileinfo
);

>> Is there a particular reason for this ?
>
> 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.

--
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Errors in _finddata64_t and _wfinddata64_t naming

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

On 24/10/16 16:00, Earnie wrote:

> On 10/22/2016 4:47 PM, Keith Marshall wrote:
>> On 22/10/16 18:02, Romain Garbi wrote:
>>> I just found that mingw has wrong names ...
>>
>> Who says they are wrong?
>>
>>> for _wfinddata64_t and _finddata64_t (which are declared as
>>> __wfinddata64_t and __finddata_t in spite of what msdn reads
>>> here : https://msdn.microsoft.com/en-us/library/zyzxfzac.aspx
>>> ).
>>
>> And that particular reference is inconsistent with several other
>> references, on MSDN, to this pair of data types; e.g.:
>> https://msdn.microsoft.com/en-us/library/kda16keh.aspx 
>> https://msdn.microsoft.com/en-us/library/zyzxfzac%28v=vs.80%29.aspx
>>
>
>>
> Sorry, Keith, I see these references with a single _ and not the
> __ underscore.

With respect, Earnie, you may wish to look again.  On the first page,
to which I have referred, (and which relates to the VS-2015 edition), I
see only __finddata64_t and __wfinddata64_t: *definitely* no mention of
either _finddata64_t or _wfinddata64_t.  Likewise, for the second of my
references, (which is an historical reference, relating to the VS-2005
edition; it wasn't until the VS-2008 edition equivalent of this latter
page -- and never in the case of the former -- that the inconsistent
references to _finddata64_t and _wfinddata64_t appeared).

> Well actually looking closely I see a reference to both.
>
> intptr_t _findfirst( const char *filespec, struct _finddata_t
> *fileinfo ); intptr_t _findfirst32( const char *filespec, struct
> _finddata32_t *fileinfo ); intptr_t _findfirst64( const char
> *filespec, struct __finddata64_t *fileinfo ); intptr_t
> _findfirsti64( const char *filespec, struct _finddatai64_t
> *fileinfo );

Sorry, but I don't see _finddata64_t in this fragment; there is only
__finddata64_t (with *two* leading underscores).  Are you, perhaps,
becoming confused by _finddatai64_t, (which is a distinct data type,
with a different structure).

>>> Is there a particular reason for this ?
>>
>> 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 also note an inconsistency WRT
_wfinddata32_t vs. __wfinddata32_t on the VS-2005 edition reference
page for the _findfirst() and _wfindfirst() functions, where every
other reference, across all VS editions, mentions only _wfinddata32_t;
that's likely a typo in the VS-2005 reference, which has nevertheless
propagated into mingwrt, so I'll adjust that too; (FWIW, this affects
only those users who have modified their MinGW-GCC installations to
avoid using MSVCRT.DLL, and who use MSVCR80.DLL, or later, instead).

Do we need yet another patch release for this?  I'd prefer to defer it
until mingwrt-5.0, (which will come much sooner, if I can stop mucking
about with cross-branch patches).

Just one final note, regarding MSVCRT.DLL vs. MSVCR80.DLL (and its
later derivatives): the _USE_32BIT_TIME_T stupidity, (which is apparent
on those reference pages cited), is *irrelevant* for *all* MSVCRT.DLL
usage of time_t, (which is *always* equivalent to __time32_t, in *all*
dependent functions exported by this DLL -- IOW, if a time_t argument
is not *explicitly* declared as __time64_t, then it is __time32_t).

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

iQIcBAEBAgAGBQJYDlMmAAoJEMCtNsY0flo/l0UQAKW5t97w0gNJV7tAMrqAuyog
/A+5gz6HGhLR/gLsQGGko/R8vwGbc6vqHg92wZ7Tv/5Y/SyY8r072Nox6q1AJQNd
Tfa0WCCs5VVWFgKAaPFfU2ySteLVxB+McXjrFESCL8MKI9qNoIUNQ26XHr8LRPVL
/L22jCh5a/OcoknDqNDtIlw2MIqpdoWLhPlVqP9yNN3C1TYSLZ+AozdQrj5rtcyq
Ma5uYycBYIU6J8hPVZAt1pb+E0owYimSQf7xyG8LjyH7qGNC/QQkKpamt9ERGjo6
SY6eql0fkl5AwuhTFT6qtX1kEE5Hy+x2XE3iFoY8PerKcUd4j9b17NBYvKAHEtFl
c5WsQPaCzLD7FqlhLEsXDvZYe8AXAbQE8G3V4YB3BkFIV9xmngXCjxDzwxVz94mZ
yysl9U43oJT36xKOxZfGMLMl5bszZa7A+ONDy9WYnlRdyLFbi0tdeewGzxu2tDRU
i68j7qQo5Ux6VBaifAcNepPDWoL25IzpOQUVmbwDtteNW9Hm/94J4J/g3HpZxarN
OWbZUR6EJkXTgJQ5Sl/6nordx6tDciGdiaYxg72GhtbeLhCrVxZf6YPriFTv3xtz
/sMV0QGkLxPjaaEMSNyoBtLMzSUbM2VM60QszmduJyZb7zNISjl3O8LImuWFWMdK
WxApTE+Z40fD0Qlm2Z+U
=jfp3
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Errors in _finddata64_t and _wfinddata64_t naming

Keith Marshall-3
-----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-----

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe

finddata64_t.patch (2K) Download Attachment
Loading...