posix clock: unexpected value for CLOCK_REALTIME when used with newlib

[sdalu]

When compiling with newlib and posix clock enabled, and so using sys/time.h,
call to clock_settime will failed due to CLOCK_REALTIME having differente values
(0 in posix/clock.c file, 1 in main.c)

CONFIG_NEWLIB_LIBC=y
CONFIG_POSIX_CLOCK=y

#include <zephyr.h>
#include <sys/time.h>
/* using posix/time.h (as in posix/clock.c), instead of sys/time.h will print 
 * a different value for CLOCK_REALTIME 
 */

void main(void) {
    printk("CLOCK_REALTIME: %ld\n", CLOCK_REALTIME);
}

[pabigot]

I'm unable to reproduce this using what you provided as prj.conf and src/main.c in samples/hello_world on nrf52840_pca10056. The build succeeds and I get:

Hello World! nrf52840_pca10056 1
***** Booting Zephyr OS build zephyr-v2.0.0-1547-gda5a595f248f *****
CLOCK_REALTIME: 1

Are you using some other platform? native_posix for example, where it does fail as you describe?

I think that would be an unsupported configuration (Zephyr's POSIX implementation surely can't co-exist with a host POSIX implementation) but defer to @pfalcon.

[sdalu]

i'm using nrf52840_mdk. Did you get 1 also using (posix/time.h):

#include <zephyr.h>
#include <posix/time.h>

void main(void) {
    printk("CLOCK_REALTIME: %ld\n", CLOCK_REALTIME);
}

[pabigot]

Sorry, I didn't read what you wrote here closely enough.

Yes, I see the values are different. I suspect the best approach here would be to work #18892 so Zephyr only provides values that are not defined by a standard header provided by the toolchain. That would need to be scheduled based on POSIX subsystem needs.

[pabigot]

This appears to be fixed by e5b462b which was hidden inside #19114 and was merged earlier today. Please re-open if it still doesn't work.

[pfalcon]

This appears to be fixed by e5b462b which was hidden inside #19114 and was merged earlier today.

More specifically, I ack and confirm this issue. It's one of many conflicts related to Zephyr's POSIX subsystem, which get tracked and persistently fixed since the beginning of this year following the approach "POSIX subsys and libc should cooperate, not compete, and newlib should be used as a pattern/convention for libc interfacing (i.e. e.g. minlibc should behave/be structured as newlibc)".

I've seen this particular issue before, but it was forgotten/lost while looking into other issue. It sufaced again while performing refactoring of #19114 based on its code review. Indeed, I would hope that the patch included there would fix the issue. I'm at a conference now though, so maybe be slow with confirming that the change also fixes this issue, so would appreciate independent verification. Thanks.

[sdalu]

It's working for me, thanks