GNOME Bugzilla – Bug 560052
Log files are retained forever on Leopard
Last modified: 2018-06-29 22:12:21 UTC
I find that my log files are never deleted using gnucash 2.2.7 (and 2.2.1) on Mac OS 10.5.5. The root cause appears to be that Leopard's strptime() is broken in that it always returns NULL when called from within gnc_file_be_remove_old_files(), even for files created by gnucash with the names such as foobar.gnucash.20081010120000.xac . The following test case shows the problem: $ cat strptime.c #include <time.h> #include <locale.h> #include <stdio.h> #include <string.h> int main(int argc, char **argv) { struct tm file_tm; const char *res; char *ext = "20081010181523.xac"; memset(&file_tm, 0, sizeof(file_tm)); res = strptime(ext, "%Y%m%d%H%M%S", &file_tm); printf("ext = %p ; res = %p\n", (void *)ext, (void *)res); return (0); } $ On Solaris this yields: $ ./strptime ext = 117b8 ; res = 117c6 $ This seems to be expected; res should point to the the character following the last character parsed, i.e. the period. On Leopard, however, the test case yields: $ ./strptime ext = 0x1fca ; res = 0x0 $ The reason why I have logged a bug against gnucash is that I see that the configure script looks for a native strptime(), presumably to use gnucash's own version if the system can't supply one. I'd like to suggest that on Leopard at least there be a simple way of telling configure to ignore the system's strptime().
N.B. I've logged 6355982 with Apple against strptime().
Well, in configure.in we use AC_REPLACE_FUNCS which basically calls AC_CHECK_FUNCS, i.e. only checks whether the given function name is declared in the system header files. It does does not special-case buggy implementations (prior MacOS versions and Windows do not provide those functions at all). In case Apple really does not want to fix its bugs, you might want to provide a way to reliably detect those implementations (or we even use the code snippets above) and then blacklist them somehow. Derek?
We could certainly write a configure test that checks if strptime() is broken (if if exists) and forces the same replacement if it is broken. But then we'd have to hope that the linker pulls in our version of strptime() instead of the broken libc version.
This appears to be fixed in Snow Leopard: $ ./strptime ext = 0x100000ec6 ; res = 0x100000ed4 $ And my log files are only 4 days old. Is this worth pursuing for Leopard, or should we close it?
*** Bug 575789 has been marked as a duplicate of this bug. ***
I've done some testing on Leopard. The bug (which is better described in http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1282424247214+28353475&threadId=1363831, though it appears in this case to apply only to the "%Y" specifier) still manifests with XCode 3.1.4 (the latest Leopard release). Interestingly, if the program is built on a Tiger machine, the bug doesn't appear; but if built (cross-compiled, since my Leopard and Tiger boxes are G4s) on a Snow Leopard machine, it fails. This rather complicates matters, as a configure test will depend on the build machine; after all, it can't see what the end-user has. ISTM we'll have to force the use of Gnucash's strptime for all OSX builds. Since libcmissing is statically linked, the state of libc (or in the case of OSX, System.framework) shouldn't be an issue. r19461 implements this.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=560052. Please update any external references or bookmarks.