Anonymous | Login | Signup for a new account | 11-10-2008 11:29 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
0001884 | [uClibc] Stdio | minor | always | 01-04-08 07:46 | 11-09-08 05:20 | |||||||
Reporter | michael_d | View Status | public | |||||||||
Assigned To | uClibc | |||||||||||
Priority | normal | Resolution | open | |||||||||
Status | assigned | Product Version | ||||||||||
Summary | 0001884: printf() field-width limit is unacceptable | |||||||||||
Description |
Uclibc includes code that tries to protect printf against large output widths. This code presents a problem, as it causes a spurious test failure in coreutils-6.9, specifically the test du/deref-args. While the feature that test is actually challenging is irrelevant to printf, it tries to create a 64k file with the command "printf %65536s x > 64k". Bash's printf builtin evidently punts to uClibc in this case, which silently treats the command as %6553s, producing a file of the wrong size. It's even worse in the current alpha coreutils-6.9.91. Among other test failures I haven't looked into yet, it has one test, "misc/printf-suprise", which verifies that "%20000000f" works under an rlimit constraint of 10000k. (Although you can weasel out of that one by arranging for printf() to return nonzero when overloaded.) I don't have a fix, save simply diking out the MAX_FIELD_WIDTH check. Note that coreutils-6.9 will show other test failures due to issue 0001869. |
|||||||||||
Additional Information | ||||||||||||
Attached Files | uClibc-0.9.30-rc3-nomaxwidth.diff [^] (871 bytes) 11-07-08 15:19 | |||||||||||
|
Copyright © 2000 - 2006 Mantis Group |