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