On 2018-12-28 9:34 a.m., Bruno Haible wrote:
This function enables syntax-check of the format string.
First question: Should this syntax-check be integrated into the
nstrftime() and fprintftime() functions? These functions are gnulib
inventions, therefore they could be extended to return
- an error indicator (maybe EINVAL?),
- a detailed error message, if you like,
- a pointer to the wrong directive in the format string, if you like.
Or is it better to have a function that does only the syntax check,
and document that nstrftime() and fprintftime() should only be called
after the syntax check has been done?
(I have no preference. Just asking.)
Both nstrtime and fprintftime silently ignore bad formats:
The comment even says:
/* Unknown format; output the format, including the '%',
since this is most likely the right thing to do if a
multibyte string has been misparsed. */
This has been the case since 1996 when strftime.c was imported from libc
(gnulib commit afabd949).
I suspect that changing this behavior would be a disruptive
backwards-incompatible change (but other opinions are welcomed).
I'd like to suggest the following new module: fprintftime-check.
For a module that does only the syntax check, I would suggest a
- The prefix 'fprint' indicates output to a 'FILE *'.
- The prefix 'str' indicates output to a 'char *' buffer.
Why not call it 'ftime-check' or 'check-ftime'?
Good idea. I'll change it.
tzalloc() may fail and return NULL. (And why would parsing the format
string be dependent on a particular time zone at all?)
nstrtime's __strftime_internal() is a complicated beast, I don't
claim to fully understand it.
But the function contains this comment:
/* POSIX.1 requires that local time zone information be used as
though strftime called tzset. */
And there is even an output "bool * tzset_called" parameter, to
let the caller know if it has been called or not - so I assume it is
critical to correct behavior of both nstrtime and fprintftime.
I will try to see if it can be disabled for the syntax-check code.