Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Wrong data type size for time_t

    Firmware developers
    2
    5
    791
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • resam
      resam last edited by

      Hi,

      I'm using macOS 10.13.3 on a modern MacBook Pro with the latest Eclipse for C++ and arm-gcc tools: gcc-arm-none-eabi-7-2017-q4-major.
      I installed both with Homebrew-Cask.

      I noticed that for some unknown reason, the data type [c]time_t[/c] is 8 bytes, instead of 4.
      This causes the static-assert in [c]src/Platform.h:661:2: error: static assertion failed: Can't fit software reset data in user signature area[/c] to fail.

      To solve this issue, I added the following compiler flag to force the ARM stdlib to use a 4-byte type: [c]_WANT_USE_LONG_TIME_T[/c], which I added in "C/C++ Build -> Settings -> Cross GCC Compiler -> Preprocessor -> Defined Symbols", same for the "Cross G++ Compiler".

      Anybody else noticed this weird behaviour?

      1 Reply Last reply Reply Quote 0
      • dc42
        dc42 administrators last edited by

        You are using the 2017q4 version of the gcc tools, whereas I am using the q2 version. Perhaps the default definition of time_t changed between versions.

        One option would be to accept the 64-bit time_t but convert it to/from unsigned 32-bits in the signature area.

        1 Reply Last reply Reply Quote 0
        • resam
          resam last edited by

          Seems you are right. I found these references:
          https://os.mbed.com/users/bomilkar/code/Testcase_RTC/
          https://os.mbed.com/questions/80116/time_t-is-broken-with-2017-q4-releas-of-/

          Thats what I get from always running the latest release 😄

          Do you plan to implement a workaround, or should I add warning to the build instructions for macOS?

          1 Reply Last reply Reply Quote 0
          • dc42
            dc42 administrators last edited by

            I will implement a workaround when I upgrade to a newer compiler. Possibly before then, but if I do then I will not test it with 64-bit time_t.

            1 Reply Last reply Reply Quote 0
            • dc42
              dc42 administrators last edited by

              I have modified the source code to declare the time field in the software reset data as 32 bits unsigned, with casts to and from time_t where necessary. This will be in the 1.21RC3 source code.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Unless otherwise noted, all forum content is licensed under CC-BY-SA