Proposal for new ISO C 9x time API

[Paul Eggert]

   Date: Mon, 21 Sep 1998 20:03:57 +0200
   From: Antoine Leca <Antoine.Leca at renault.fr>

   - I am not really happy that xtime_get does not return the value
   of the readed clock

I agree.  I'm working on a set of proposed changes to Markus Kuhn's
spec.  One part of the proposal changes xtime_get's signature to be
the following:

	    xtime_t xtime_get(int clock_type);

This is simpler, and will make xtime_get easier to use in practice, as
the programmer won't have to worry about taking addresses of time
objects.  Avoiding addresses also let things run a bit faster on
modern architectures; this can be helpful for fine-grained timing
measurements.

   - similar with tz_error, there might be a need for
   xtime_conv_error,

I think it's simpler, and more in accordance with existing practice,
to let strerror and perror handle error numbers.  We shouldn't need a
separate error-string-generator just for times.  That's too
complicated; such a generator would also has to worry about locales
and the like.  Just let strerror do it -- that's what strerror is for.

(I don't mean to suggest that we should use errno; I'd rather avoid
errno, and I hope my proposed changes won't use errno.)

   - there should be a way to determine how to size the buffer for
   strfxtime

Absolutely.  strftime botches this -- e.g. there's no portable way to
distinguish an error return from a format that generates an empty
string!  This must get fixed in any rewrite.

   The only remaining point I have if about procedures.
   I think the best way to do is to formally present this proposal
   at the WG14 meeting, at Santa Cruz, California, on October 5-9.

I think it's too soon to present such a proposal; it hasn't been
reviewed enough yet, and it hasn't been implemented (preferably by two
independent implementations), tested, and used.

Also, I suspect that the working-group schedule is such that it's not
feasible to introduce this proposal for C9x.  I think we're better off
proposing it for C0x, or as a normative addendum to C9x sometime
between C9x and C0x.