Secondo opengroup
Il membro tv_nsec è valido solo se maggiore o uguale a zero e minore del numero di nanosecondi in un secondo (1000 milioni). L'intervallo di tempo descritto da questa struttura è (tv_sec * 10'-.4m'9'.4m'+ tv_nsec) nanosecondi.
Quindi, secondo opengroup, sembra ufficiale che debba durare meno di 1 secondo.
Sono abbastanza certo che la risposta sarà sempre "no".
clock_gettime non tornerà con tv_nsec>=10e9. clock_settime() e clock_nanosleep() pongono entrambi questa restrizione sui loro input, quindi ho sempre pensato che clock_gettime fosse coerente con questo.
Anche su Linux + glibc, se scavi abbastanza in profondità in glibc, vedrai un codice come questo:
Estratto da glibc/nptl/pthread_clock_gettime.c:
/* Compute the seconds. */
tp->tv_sec = tsc / freq;
/* And the nanoseconds. This computation should be stable until
we get machines with about 16GHz frequency. */
tp->tv_nsec = ((tsc % freq) * 1000000000ull) / freq;
Ciò si verifica anche in glibc/sysdeps/unix/clock_gettime.c.
Ma hai ragione, le pagine man non lo dicono. Almeno non quello che c'è nella mia distribuzione Linux o su opengroup.org. Quindi l'implementazione è tecnicamente soggetta a modifiche senza preavviso.
Se stai scrivendo per Linux + glibc, direi che sei al sicuro. Puoi controllare tu stesso le librerie libc open source alternative, ad es. Bionic di Android o la newlib ridotta.
Se stai prendendo di mira qualche altro sistema POSIX closed source, tu o il tuo cliente avete problemi a pagare per il supporto, quindi chiedete al fornitore se non è documentato.
Se cerchi di essere il più portatile possibile e ti senti paranoico, avvolgi clock_gettime con una funzione di "normalizzazione" come questa:
int my_gettime( struct timespec * ts )
{
int ret;
if( 0 == (ret = clock_gettime(SOME_CLOCK, ts))
{
while (tv_nsec >= 1000000000 )
{
ts->tv_nsec -= 1000000000;
ts->tv_sec += 1;
}
}
return ret;
}