Proposal for new ISO C 9x time API

[Antoine Leca]

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