Ken Pizzini wrote on tz@elsie.nci.nih.gov:

In message <199809182051.NAA01889@shell7.ba.best.com>, Nathan Myers <ncm@best.com> writes:

...

Can we discuss the rest of the proposal?

:-)

Well, part of the reason for my focusing on the trivial issue of what to name the basic data type is that I'm pretty happy with the real substance.

I agree with Ken here. Outside trivial name-related issues or the editorial-related problems, my only points are: - 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) - similary, xtime_conv may perhaps return the result (dst), or NULL if an error intervenes - about xtime_delay, it should have some ways for this function to be not supported by implementations. 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). - 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). - 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? 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? Antoine

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

Antoine Leca wrote on 1998-10-02 13:27 UTC:

My real concern is that lazy implementers (there are a lot of them) may, and probably will, implement it as a busy wait on some platforms, while other resources may be perhaps available, but probably more difficult to use. That is what I did not like. Also, I do not like the sad effect: if xtime_delay *could* be implemented as a busy wait, there will be some programmers that will refuse to use it for effiency reasons (look at the people that rewrite memmove because some implementers wrote it using malloc... thus avoiding the speedy block moves implemented by others :-( ).

But you are right that a "delay" statement (in one way or another) is a practical quest for a fair number of people.

I have been following issues related to international standardization for around a decade now. One of the important things that I have learned is that IT standards are not a suitable instrument for ensuring the quality of software products. Standards (if very carefully written) are a reasonable good aid (but not a guarantee!) in helping implementors to create portable products. The quality of a software product depends exclusively on the skills and motivation of the implementor, and no possible standard can ensure a high quality implementation (except if you specify the entire product byte-by-byte, which is equivalent to making is available freely -> the Olson library). We have other mechanisms to ensure quality, namely the market and user feedback. Standards help to create a fair market, because they allow you to build your infrastructure independent of individual suppliers. This gives you as the customer the opportunity to avoid the lazy implementor and chose the most competent one. So please let's not get into discussions about what lazy implementors might do with a specification. Trust me: if you do use products from a lazy implementor, you will have problems anyway, no matter what you write in the standard. 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/>

"Clive D.W. Feather" wrote on 1998-10-08 19:25 UTC:

This is not the right standard for a delay function; that's a much more OS-specific operation and belongs in an OS standard like POSIX.

Just the same as "kbhit()" doesn't belong in the C Standard.

The distinction of what belongs into a programming language standard and what belongs into an OS standard is generally pretty arbitrary and based mostly on historic accidents. Some languages (Java and Ada come to mind) for instance say that concurrency (multi-threading) and scheduling belong into the programming language standard, while others (C, Fortran, Pascal) leave this to OS API standards such as POSIX and Win32. In Ada, delay is even a reserved keyword (like return) and not just a library function (mostly because delay can not only be used as a statement of its own but also to timelimit alternatives in select statements). C does contain numerous functions that do block on external events (getchar()), and it does contain a clock interface, so I see no convincing argument of not also including a function that would allow one to block on a clock. For me, a delay function is just another form of accessing a clock, something very similar to reading a clock. 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/>

Ken Pizzini wrote on 1998-09-19 07:54 UTC:

One other fragment that mildly bothers me is in the Implementation Advice to {xtime,chron{,os}}_conv(), where Markus has: : Implementations can also offer the application to : convert TIME_MONOTONIC values into TIME_TAI or TIME_UTC values as soon : as these clocks have been adjusted using an external reference. This : way, TIME_MONOTONIC values that were measured at a time when the : implementation had not yet been able to determine UTC or TAI can later : be converted as soon as contact with the reference clock is : established.

I feel that it would be helpful to further advise implementors on what they might do (or at least that it is an issue that they ought to consider) if, after synchronization with TIME_UTC or TIME_TAI becomes established, it is discovered that the TIME_MONOTONIC clock has been running with its "second" of a substantially different duration than a TAI second? (Say, 0.1 TAI second/pre-sync monotone second, or 10 TAI seconds/pre-sync monotone second, perhaps due to a change in underlying hardware that the software is running on, and without a suitable pre-syncronization time base to calibrate to. Even a (perhaps more realistic) 1.01 TAI second/monotone second could be considered "substantial" by some.)

Perhaps add a sentence along the lines of: When making such a conversion, a high-quality implementation would take into account any difference in clock-rates that may have been discovered.

Significantly differing clock rates (larger than 1000 ppm) would clearly be a hardware malfunction, and I don't think the C standard is the place to address these. Typical cheap PC crystals have a frequency error of usually much better than 300 ppm (mine here wandered in the last hour between -15 and -22 ppm, says the ntpq command). The constant manufacturing error and the time-dependent fluctuations (due to temperature and voltage fluctuations) are roughly in the same order of magnitude for office equipment. If you measure the frequency error as soon as you got access to an external clock, this does not necessarily significantly allow you to estimate the frequency error history of your oscillator. Unless you have rather bad hardware with a quite severe manufacturing error (in which case for instance NTP's control algorithms would overflow and fail anyway), it is not very practical to offer an a posteriori correction of the frequency error. 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/>