GNOME Bugzilla – Bug 136283
make check: printf-test FAILED
Last modified: 2011-02-18 16:07:29 UTC
GLib-ERROR **: gmem.c:140: failed to allocate 18446744069414584325 bytes aborting... /bin/sh: 18168 Trace/BPT trap(coredump) FAIL: printf-test This looks like a pure 32<>64 bit problem ...
glib-2.3.5
make check succeeds on various 64-bit platforms, though it's quite possible there is code being triggered under HP/UX that isn't triggered under Linux. It would be very helpful if youram printf-test under a debugger and get a backtrace of where the abort occurs.
197 TEST (NULL, g_snprintf (buf, 128, "%*s", -5, "abc") == 5 && !strcmp (buf, "abc ")); 1: buf = " abc\000+00\000+00", '\0' <repeats 15 times>, "@\000V°\200\000\003ÿÿ~ä\200\000\000\000\000\000\000\000@", '\0' <repeats 19 times>, "\002\000\000\000\000\000\000\000\000\000\000\002", '\0' <repeats 23 times>, "\0040@\000\000\000\000\000(È", '\0' <repeats 15 times> (gdb) n GLib-ERROR **: gmem.c:140: failed to allocate 18446744069414584325 bytes aborting... Program received signal SIGTRAP, Trace/breakpoint trap. 0x800003ffff5ff4e4 in kill () (This is on glib-2.3.6)
Needs detailed debugging, not obvious.
My suspicion is that negative precision is not covered by SUS, and is a glibc extension. Maybe the test should use "%-*s".
Actually, SUS says: A field width, or precision, or both, may be indicated by an asterisk (*). In this case an argument of type int supplies the field width or precision. Arguments specifying field width, or precision, or both must appear in that order before the argument, if any, to be converted. A negative field width is taken as a - flag followed by a positive field width. So negative width *is* covered by the standard. Maybe HPUX just doesn't get that particular case right. I'll probably just comment the one testcase out.