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