#1973 _USE_32BIT_TIME_T issue.

WSL
pending
Earnie Boyd
None
Bug
fixed
Feature_in_WSL_4.0
False
2013-06-26
2013-05-16
Earnie Boyd
No

Related

Issues: #1975
Issues: #1984

Discussion

<< < 1 .. 7 8 9 (Page 9 of 9)
  • Earnie Boyd
    Earnie Boyd
    2013-06-19

    statdemo.c (attached with earlier posting on this ticket) not yet.

    I've resolved it in my local repository. I tried to push but SF is having issues. I'll try the push again later.

     
    • Earnie Boyd
      Earnie Boyd
      2013-06-19

      SF finally became responsive. I've pushed the changes for _findfirst and _findnext as well as removing the time_t definition in wchar.h which should not have been in that file.

       
  • Earnie Boyd
    Earnie Boyd
    2013-06-19

    Less critically, because in the Microsoft world long probably always does represent a 32-bit entity, but in the ISO-C world "whatever that might be" may become significant; a long is required only to be >= 32-bits, (and is 64-bits, on 64-bit Debian for x86_64). We need __time32_t to be definitively equivalent to int32_t, (from stdint.h), and __time64_t to be equivalent to int64_t; time_t should then be equivalent to one or other of these definitive underlying types, and IMO, it's better to define accordingly.

    See http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows

    Windows uses LLP64 meaning a "long long" data type is 64 bits and long and int data types are 32 bits. Linux uses LP64 meaning that int data types are 32 bits and long and "long long" are 64 bits. A pointer is 64 bits on both.

    Hopefully the cross compiler will DTRT w.r.t. the data types when the target is Windows but that should be reflected in the coding for the cross and not the native libraries.

     
    Last edit: Keith Marshall 2013-06-20
    • Keith Marshall
      Keith Marshall
      2013-06-20

      See http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows

      Thanks for this. The top level response does rather support my advocacy for use of deterministic types, such as int32_t, rather than potentially ambiguous long. (It does erroneously state that these are defined in inttypes.h; they are actually defined in stdint.h, which inttypes.h is required to #include).

      Hopefully the cross compiler will DTRT w.r.t. the data types when the target is Windows but that should be reflected in the coding for the cross and not the native libraries.

      I respectfully disagree. Poor software engineering should not be so casually dismissed. Where an explicit 32-bit type is required, use of an ambiguous type such as long to specify it is poor engineering, at best. The intent should be explicitly specified as int32_t, regardless of whether for native or cross use. Declarations from the native environment are sometimes required to propagate into the cross; when native is poorly engineered, that may have disastrous consequences. (Witness our earlier discussion, on mingw-dvlpr, w.r.t. my port of pexports to 64-bit Linux; the original natively inspired declaration of the IMAGE_DOS_HEADER structure, among others, declares 32-bit fields as typedef long LONG -- only reliably 32-bits on LLP64 Windows, but 64-bits on LP64 Linux -- resulting in an immediate segfault crash of the cross hosted tool. To circumvent that, I had to explicitly kludge it to typedef int32_t LONG -- reliably 32-bits everywhere -- rather than the original ambiguous typedef long LONG. With better engineering up-front, this issue wouldn't even have arisen).

       
  • Keith Marshall
    Keith Marshall
    2013-06-26

    Frustratingly, still broken. See test case attached to [#1989].

     

    Related

    Issues: #1989

<< < 1 .. 7 8 9 (Page 9 of 9)