Web lists-archives.com

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

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

- -- 

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Version: GnuPG v2.0.20 (GNU/Linux)


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

This list observes the Etiquette found at 
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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe