Bruno Haible <[email protected]> writes: > Paul Eggert wrote: >> >> So CTIME_BUFSIZE should be 35? >> > With 50 years of computer science experience, we should have learned >> > the lesson to allocate more room than sounds necessary*now*. If >> > now you think 35 will be sufficient for all times, then we should >> > better choose twice that value: 70. >> >> We needn't be that pessimistic. We can use something like this: >> >> #define CTIME_BUFSIZE \ >> (sizeof "Wed Jun 30 21:49:08 \n" \ >> + INT_STRLEN_BOUND (time_t) - 7) > > This formula reflects *today*'s expectations. My point is that we > should be prepared for the unexpected events. Such as the U.S. > adopting the French Republican calendar with its longer month > names (germinal, brumaire, etc.). Or that the abbreviation and > padding habits change.
I think support for those unexpected events belong in your more properly designed str_to_time API family, rather than in a smallest safe replacement for the existing US/English/Gregorian/ISO8601-centric poorly designed ctime API, that for simplicity should continue to be US/English/Gregorian/ISO8601-centric. That means we ought to encourage people to consider the str_to_time API when they fix existing occurances of ctime. It seems some code will need the predictable behaviour from the safer_ctime/strctime API I'm thinking of, and some code will prefer a more human-friendly approach that str_to_time can support. /Simon
signature.asc
Description: PGP signature
