[adding bug-gnulib] On 05/25/2017 12:43 AM, Steven M. Schweda wrote: > Tru64 is not alone. On an old HP-UX system, it's different but still > sub-ideal: > > dy# findutils-4.6.0/find/find . -name fred -printf '%C+\n' > May+16:18:11.0000000000 > > There, "man strftime" says: > > [...] > The following directives are provided for backward compatibility with > the directives supported by date(1) and the ctime(3C) functions. > These directives may be removed in a future release. It is > recommended that the directives above be used in preference to those > below. > [...] > %F Locale's full month name (use %B instead). > [...] > > So, again, trusting the non-GNU strftime() seems unwise.
Gnulib just recently had a cleanup where we realized that the 'strftime' module was misnamed: https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00167.html https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00022.html So yes, either findutils should be using nstrftime() and not strftime() (which will guarantee that these sequences work), or it is indeed time to patch gnulib to provide a replacement strftime() on platforms that are not POSIX-compliant (and then still patch findutils to use the newer gnulib). It's actually probably easier it findutils just starts using nstrftime(), regardless of what else gnulib does, but it's at least pointing out that gnulib should be documenting the known pitfalls in native strftime() implementations. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature