Menu
▾
▴
Re: [Mingw-users] time_t type and dirent.h functions in WSL 4.0
|
From: Diego C. <dca...@gm...> - 2013-10-12 22:40:57
|
I think Eli is correct, but that would be a problem only If A)
libmingwex.a isn't keep updated with the rest of the packages
(considering 4.8.1-4 now uses _USE_32BIT_TIME_T by default), B) if
_USE_32BIT_TIME_T is defined by default, and someone undefines it, or
C) yet worse, _USE_32BIT_TIME_T isn't defined by default within gcc
include files, causing dirent to always use 64b time_t while the gcc
libs are using 32b
I.e trying to access dirent->d_time_access would bring to lower 32b
bound of d_time_create
Just my 2cents.
Cheers.
2013/10/12 Earnie Boyd <ea...@us...>:
> On Sat, Oct 12, 2013 at 8:18 AM, Eli Zaretskii wrote:
>> I'm posting this here first because I might be missing something. If
>> my observations are correct, and this is a bug, I will open a ticket.
>>
>> The layout of 'struct dirent' in WSL 4.0 uses the time_t type:
>>
>> struct dirent
>> {
>> long d_ino; /* Always zero. */
>> unsigned short d_reclen; /* Always zero. */
>> unsigned short d_namlen; /* Length of name in d_name. */
>>
>> /* The following exactly mimic the layout of _finddata_t ...
>> */
>> unsigned d_type; /* File attributes */
>> time_t d_time_create;
>> time_t d_time_access; /* always midnight local time */
>> time_t d_time_write;
>> _fsize_t d_size;
>> /*
>> * ...so that we may map a union of _finddata_t at the
>> * location of d_type (corresponding to _finddata_t.attrib),
>> * and thus map this directly to the _findfirst/_findnext
>> * returned field.
>> */
>> char d_name[FILENAME_MAX]; /* File name. */
>> };
>>
>> However, the width of time_t can be either 32 bits or 64 bits, with
>> the latter being the default in 4.0:
>>
>> #if defined(_USE_32BIT_TIME_T)
>> typedef __time32_t time_t;
>> #else
>> typedef __time64_t time_t;
>> #endif /* _USE_32BIT_TIME_T */
>>
>> Presumably, when the dirent functions were compiled for inclusion in
>> the libmingwex library, the compilation used the 64-bit default
>> definition of time_t.
>>
>> This means that applications that define _USE_32BIT_TIME_T will use an
>> incompatible definition of 'struct dirent', which will break any code
>> that calls the dirent functions.
>>
>> Am I missing something? If not, it sounds like 'struct dirent32' and
>> readdir32 etc. functions will be needed to allow use of both 32-bit
>> time_t and dirent functions in the same program, similarly to what is
>> already done with time-related functions, 'stat', etc.
>
> I don't know if you're missing something or not. I spent considerable
> amount of time debugging _USE_32BIT_TIME_T using TCL/TK as the basis
> of testing. Can you provide an example of proof of brokenness? If so
> then open a ticket.
>
> --
> 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=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe
|