Wrong data type size for time_t

resam · 21 Feb 2018, 15:30

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?

dc42 · 21 Feb 2018, 18:32

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.

resam · 21 Feb 2018, 18:55

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?

dc42 · 21 Feb 2018, 19:51

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.

dc42 · 22 Feb 2018, 10:19

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.