Type mismatch between PRIi64 and time_t on 64-bit builds

[mlasch]

There is a build warning when I try to build code which prints a time_t timestamp. It only happens when building for a 64-bit targets like qemu_x86_64 or xenvm. It does not occur on 32-bit builds.

zephyr/samples/posix/gettimeofday/src/main.c:25:24: warning: format '%lli' expects argument of type 'long long int', but argument 2 has type 'time_t' {aka 'long int'} [-Wformat=]
   25 |                 printf("tv_sec: %"PRIi64"\n", tv.tv_sec);
      |                        ^~~~~~~~~~~            ~~~~~~~~~
      |                                                 |
      |                                                 time_t {aka long int}

The reason seems to be a mismatch between die variable size of time_t (long int) and the format macro PRIi64 (long long int). Maybe PRIi64 should be a long int on 64-bit architectures?

To Reproduce
This can be reproduced by adding a string format which uses the PRIi64 macro and a time_t variable.

Expected behavior
time_t is 8 bytes and should be able to be printed with PRIi64 on every platform.

Environment:

• OS: Linux amd64/arm64
• Toolchain Zephyr SDK 0.17.0
• Tested on current main

[cfriedt]

I'm kind of confused about this. The line referenced above does not seem to exist in the sample.

https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/posix/gettimeofday/src/main.c#L31

Was this is a user-added printf statement?

This can be reproduced by adding a string format which uses the PRIi64 macro and a time_t variable.

Ah, I see that was the case.

It's possible to keep PRIi64 and simply add a cast like (int64_t) to the parameter passed to printf.

Additionally, neither time_t nor PRIi64 are specific to POSIX, since that was part of C99 integer typing.

https://en.cppreference.com/w/c/types/integer

Converting to discussion, this does not appear to be a bug.

[mlasch]

Was this is a user-added printf statement?

yes, the code is not committed, I just used it as an example.

It might be an issue with picolibc.

native 64-bit Linux (Ubuntu)
On my Ubuntu Linux amd64 system, the underlying data type of time_t is #define __SLONGWORD_TYPE long int and PRIi64 evaluates to li.

echo -e "#include <inttypes.h>\n PRIi64" | gcc -E -

Both match so printf("%" PRIi64, variable_with_type_time_t); produces no error.

Zephyr on a 64-bit target platform
When I compile the same code with the Zephyr SDK for qemu_x86_64/atom, time_t eventually result in a long int.

time_t -> __time_t -> _TIME_T_ -> long

From `.local/opt/zephyr-sdk-0.17.0/x86_64-zephyr-elf/picolibc/include/sys/_types.h:227

#if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL
#define	_TIME_T_ long     <------ THIS LINE
#else
#define	_TIME_T_ __int_least64_t
#endif
typedef	_TIME_T_	__time_t;

At the same time PRIi64 evaluates to lli on Zephyr which creates the compiler warning. Either PRIi64 should be a li on amd64 and arm64 and not lli or time_t should be a long long int the same as int64_t. My main issue here is that there is a mismatch between time_t, int64_t and PRIi64 they are all 8 byte long, but with different underlying data types.

Is it ok that Zephyr uses different definitions for PRIi64 than Linux on the same target platform?

Of curse I can always cast time_t to int64_t which turns the variable from long to long long, but I don't think it is a nice solution. I hope this describes my issue better. I'm not an libc expert. I just think the data types should be consistent.