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/>