Hi Mark, On Sat, Feb 08, 2025 at 05:25:33PM -0800, Mark Harris wrote: > > > - Calls to these functions are not technically equivalent to any > > > clock_* function call; at least the return value will be different. > > > > It would be interesting to clarify if they are equivalent except for the > > return value. > > The clock_* functions also specify that errno is set to certain values > on error, but the timespec_* functions do not guarantee this. So > instead I just state that the time and resolution are the same. Makes sense. > > > .SH RETURN VALUE > > > -On success, > > > +.BR timespec_get () > > > +returns the nonzero value > > > > I think I'd remove "value". What do you think? > > Ok, if you think that is sufficiently clear I will remove "value" and > s/represents/is/ (below). Yeah, that sounds good. > > > +.I base > > > +if it represents a supported time base > > > +and the current time was successfully retrieved, or 0 otherwise. > > > > D'oh. Someone designed another non-standard return value. <facepalm/> > > I agree that the return value is unusual, but of the dozens of > interfaces to get high resolution time we have finally stumbled onto > one that Linux, BSD, macOS, and Windows could all agree to support (at > least for TIME_UTC), and the unusual return value is less ugly than a > bunch of #ifdefs. Yeah, that's good. I'm just complaining that these people could have just spent a little bit more on the design of the API, and returned a 0/-1 code as is usual for standard APIs. Returning the base is just nonsense, because the caller already has it, unless I'm missing some weird use case that they had in mind. :) I see the revision in my mailbox; I'll check it in a moment. Thanks! Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
