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