On 8/8/20 3:01 PM, Robert Elz wrote:
It turns out not to matter here really, as it is trivial to arrange that a successful call always returns >= 1, leaving 0 to always mean that an error occurred (after which errno can be checked).
It's not that easy in general-purpose functions that call strerror. The tzdb's date.c program, for example, does this: cp[0] = '\1'; result = strftime(cp, size, format, tmp); if (result != 0 || cp[0] == '\0') /* strftime worked */; and this relies on undocumented but we-hope-portable-in-practice properties of strftime. If we knew that strftime preserved errno on a successful return of 0, we could make this code use that property and it'd be portable and easier to understand. One can work around the problem by allocating memory for a larger format (take the original format and prepend a space, then strip a leading space from the output), but that's awkward and inefficient and hardly anybody does it. Really, the strftime API needs to be fixed. I submitted a bug report to POSIX about this, here: https://www.austingroupbugs.net/view.php?id=1386 which proposes that errno should be preserved on successful returns of 0 from strftime. As it happens, Dennis Wölfing already reported the same spec bug here: https://www.austingroupbugs.net/view.php?id=1353 I hope that the POSIX committee accepts one or the other of the suggested changes.