Issues with clock_gettime(CLOCK_REALTIME, &wait) pre macOS 10.13

[Christopher Jones]

Hi,

> I have been pondering a good way to make it add the header definition properly ( ? use specific headers such as string.h injected ahead of the system search directory and "include_next", perhaps?) and also possibly to make each definition selectable, or at least OS-version groups blocked off with guards.

I’ve been experimenting in the direction of the above, and I think there is some milage to this approach.

I’ve attached a couple files to this mail.

time.cpp - A basic test application

time.h - A wrapping header that uses include_next to wrap time.h adding an implementation of clock_gettime for OSX10.11 and older.

I *think* I have made it reasonably complete, in that if I compare what I get on macOS10.14 (so using the system implementation) to that on OSX10.10 I see

 > ./mac1014.exe 
CLOCK_REALTIME  1540330516865744000
CLOCK_REALTIME  1540330516865769000
CLOCK_REALTIME  1540330516865773000
CLOCK_REALTIME  1540330516865776000
CLOCK_REALTIME  1540330516865779000
CLOCK_REALTIME  1540330516865782000
CLOCK_REALTIME  1540330516865785000
CLOCK_REALTIME  1540330516865789000
CLOCK_REALTIME  1540330516865792000
CLOCK_MONOTONIC 692301875594000
CLOCK_MONOTONIC 692301875598000
CLOCK_MONOTONIC 692301875601000
CLOCK_MONOTONIC 692301875606000
CLOCK_MONOTONIC 692301875609000
CLOCK_MONOTONIC 692301875612000
CLOCK_MONOTONIC 692301875615000
CLOCK_MONOTONIC 692301875619000
CLOCK_MONOTONIC 692301875622000

 > ./mac1010.exe 
CLOCK_REALTIME  1540330771661752000
CLOCK_REALTIME  1540330771662759000
CLOCK_REALTIME  1540330771662770000
CLOCK_REALTIME  1540330771662776000
CLOCK_REALTIME  1540330771662783000
CLOCK_REALTIME  1540330771662789000
CLOCK_REALTIME  1540330771662795000
CLOCK_REALTIME  1540330771662801000
CLOCK_REALTIME  1540330771662807000
CLOCK_MONOTONIC 3731777139000
CLOCK_MONOTONIC 3731777145000
CLOCK_MONOTONIC 3731777151000
CLOCK_MONOTONIC 3731777157000
CLOCK_MONOTONIC 3731777162000
CLOCK_MONOTONIC 3731777168000
CLOCK_MONOTONIC 3731777174000
CLOCK_MONOTONIC 3731777180000
CLOCK_MONOTONIC 3731777186000


The REALTIME clock is supposed to give values roughly the same in both cases, as these are supposed to be absolute wall clock times since the UNIX epoch. 

MONOTONIC is allowed to have different values, as its w.r.t. different points for each machine. 

Compilation is just a case of

 > ls *.h *.cpp
time.cpp	time.h
 > clang++ -I. time.cpp -o mac1010.exe
 >

If you remove the -I. then on 10.10 it correctly fails.

 > clang++ time.cpp -o mac1010.exe
time.cpp:26:45: error: use of undeclared identifier 'CLOCK_REALTIME'
    std::cout << "CLOCK_REALTIME  " << time(CLOCK_REALTIME) << std::endl;
                                            ^
time.cpp:31:45: error: use of undeclared identifier 'CLOCK_MONOTONIC'
    std::cout << "CLOCK_MONOTONIC " << time(CLOCK_MONOTONIC) << std::endl;
                                            ^
2 errors generated.

so the include_next seems to work OK.

I have tried with a number of gcc and clang compilers, and it seems fine with them all.

So I *think* we could consider including the wrapper time.h in the snowleopardfixes port, and then as long as builds use -I${prefix}/include then should pick it up without having to patch the code in any way, which is my aim here...

Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: time.h
Type: application/octet-stream
Size: 835 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181023/63185be2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time.cpp
Type: application/octet-stream
Size: 640 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181023/63185be2/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1930 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181023/63185be2/attachment.bin>