Proposal for new ISO C 9x time API

[Markus Kuhn]

Antoine Leca wrote on 1998-09-21 18:03 UTC:
> - I am not really happy that xtime_get does not return the value
> of the readed clock (because dialects like
>   strfxtime(buff, sizeof buf, "%c", xtime_get(0, xxx), Local_tz);
> will then become very easy to write), but the current solution
> is certainly almost as readable inpractice, and it avoids the *int
> parameter from the first idea of Markus (that I did not like)

As long as clock can be unavailable and as long as we are in a programming
language without an exception mechanism, the only proper way to use
xtime_get is inside exception handlers such as:

  struct xtime now;

  if ((xtime_get(&now, CLOCK_UTC) & CLOCK_UTC) != CLOCK_UTC) {
    sprintf(buf, "clock unavailable");
  } else {
    strftime(...)
  }

> - similary, xtime_conv may perhaps return the result (dst),
> or NULL if an error intervenes

How should this work: NULL is not a struct xtime value. I hope you do
not suggest to return a struct xtime * value to a static buffer
(multi-threading safety). I think my version is more convenient to
use here.

> - about xtime_delay, it should have some ways for this function
> to be not supported by implementations.

I don't agree.  See below.

> Some implementations have no user-usable timers (MS-DOS comes to
> my mind), so the only way to effectively implement this is
> to stop any activity and wait until the main clock reaches some
> point of time... This is not efficient (IMHO).

On non-preemptive operating systems such as MS-DOS, obviously the
xtime_delay() has to be implemented as a busy wait. If you consider this
inefficient, you should seriously consider buying an operating system
with preemptive multi-tasking ... ;-)

Of course the application designer has to be aware of whether the
operating system can do blocking delays or only busy waits. Allowing
xtime_delay() not to be implemented at all doesn't gain you anything. It
can always be implemented in some form as long as some kind of clock
(including the CPU clock signal) is available. Allowing it to be not
implemented just causes paranoid programmers to add useless exception
handlers. Practically all MS-DOS programming languages have some form of
a delay statement.

> - similar with tz_error, there might be a need for
> xtime_conv_error, which will sumarize the reasons why any functions
> from xtime_make, xtime_break, xtime_conv or strfxtime have
> previously failed (examples of reasons are: "lack of needed
> informations", "source time does not exist", and the usual
> cases from failed validations of the parameters, or lack of memory).

I don't agree. tz_prep processes complex and directly user-provided
input (e.g., a timezone string found in a config file, command line
option, input field, or environment variable). For user provided complex
input, a powerful error feedback interface is useful. For the failure of
the other commands, the reason for the failure should usually be pretty
obvious, and the errors would be related to data that can easily be
checked by the application. An extra error message facility for every
single function does not agree with the design principles of the classic
C library: atoi and scanf also do not tell you what failed.

> - there should be a way to determine how to size the buffer for
> strfxtime without resorting to tricks (read: kludges) like
> mallocating a buffer of the heap and, if the call fails, doubling
> the buffer before re-issuing the call. Others similar functions
> return the space needed when the s parameter is NULL. Is it worth
> the need?

This might be something worth thinking about.

> Anyway, all of this is pretty secondary. I shall say that I find
> this proposal very attractive, and that it is easy to use *and*
> very powerful.

> 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.
> Unfortunately, I cannot come at such a meeting, so I cannot
> "champion" it. Is somebody interested by such a role, which
> is really needed if we want this proposal to be effective in
> the next revision of the C standard?

I certainly do not have the funding to go there myself. I also still
have not been in direct contact with any BSI IST/5 member on this. I
have heard that there is a pretty good chance that the current draft
will be rejected for reasons that are much more fundamental than the
library (especially some of the new numerics stuff is said to be
dubious), so I hope we might get more time.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>