Re: _tfinddata64_t

On Fri, Oct 18, 2013 at 1:11 AM, Keith Marshall wrote:
> Guys,
>
> While formulating the patch attached to issue #2106:
> https://sourceforge.net/p/mingw/bugs/_discuss/thread/07cb5e66/60ea/2b4b/attachment/dirent-2106.patch
>
> I've noticed, and corrected, anomalies in io.h, wchar.h, and tchar.h,
> relating to a data type formerly identified as _wfinddata64_t.  MSDN
> does not refer to this type; all indications suggest that it should be
> __wfinddata64_t instead, and I've modified the headers accordingly.
>
> In tchar.h, for the non-unicode case, I also see a reference to a
> corresponding _finddata64_t; MSDN suggests that this too should have an
> additional leading underscore, becoming __finddata64_t; (indeed, all of
> our other headers do seem to refer to it as such).
>
> Actually, MSDN doesn't seem to mention any mapping for:
>
>   _tfinddata64_t --> __wfinddata64_t   (unicode case)
>   _tfinddata64_t --> __finddata64_t    (non-unicode case)
>
> and I'm having a hard time seeing what value they might have; (they do
> not seem to be referred to, at any other point throught the WSL code).
>
> So, should we also adjust the non-unicode case for _tfinddata_t, in
> tchar.h, or should we just drop these altogether?

No.  See http://msdn.microsoft.com/en-us/library/se784sk6.aspx.

We also might want to map the misnamed types to the corrected names
for the 4.0.4 point release and remove the mapped types in 5.0.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk