Markus Kuhn wrote:
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 [...]
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:
OK OK OK, I already knew it. ;-) (I was more thinking about "quick-and-dirty" programming, where we all know for sure that the clock *is* available). Of course, as I said, your design is better on the long term.
- 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.
My mistake (I wrote struct xtime while I intended a pointer to it; and of course the latter is wrong).
- 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).
If you consider this inefficient, you should seriously consider buying an operating system with preemptive multi-tasking ... ;-)
Tell this to my >20,000 users that do *not* want to migrate. ;-)
Practically all MS-DOS programming languages have some form of a delay statement.
MS-DOS was intended to be an extreme example. 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. [about explaining mistakes]
atoi and scanf also do not tell you what failed.
atoi even do not tell you when it failed! ;-) [about C9X]
I have heard that there is a pretty good chance that the current draft will be rejected for reasons that are much more fundamental
I shall not bet about this, since the ANSI Committee is very volunteer to go ahead with the current state of affairs. Also, BSI seems to me pretty alone on this "fundamental" point. If anyone is willing to act upon the process of C9X, I remind you that public comments can be made about it. Refer to <http://www.ncits.org/fcd9899/fcd9899.htm> for more informations. Also note that AFAIK, ANSI is still willing to accept public comments from anyone, not just US citizens or residents. The dead line is November 10th. At least, Markus, you should provide your current proposal this way (the ANSI Committee will then be forced to statute over the proposal). If you are not from the USA, you can also address yourself to your national Standardization body. Usually, once you get access to the informed people, they are very interested to get the advice from real experts of the field (but don't expect to be paid for the consultation!) The deadline in this case is more far away (as far as January 8th, I think). Anyway, even if the current draft for C9X fails, I believe we should formally publish to the Committee the current proposal, just to "take date" and to avoid the inclusion of struct tmx stuff in real-world implementations (which will be desastrous, I think). Antoine