BusyBox Bug and Patch Tracking
BusyBox
  

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

- Relationships

- Notes
(0015254)
michael_d
11-07-08 15:19

I've looked into this issue more closely, and found that there doesn't seem to have been any need for the small MAX_FIELD_WIDTH value. The underlying machinery can cope with the full range of an "int", and (with the check removed), can even output the correct number of bytes on "%2147483647d" without using excessive memory.

It looks like the test was only there to prevent the code that converts the digits in the format string into an "int" value from overflowing.

I'm sending a patch which removes the MAX_FIELD_WIDTH define, and replaces the overflow check with one that will safely allow any value up to INT_MAX. Higher values are replaced with INT_MAX, which probably breaks the standard but is saner than the previous behavior, which would just use only the most significant four or five digits.
 
(0015304)
bernhardf
11-09-08 05:20

Can you provide testcases to be put into test/stdio/printf-width.c please?
 

- Issue History
Date Modified Username Field Change
01-04-08 07:46 michael_d New Issue
01-04-08 07:46 michael_d Status new => assigned
01-04-08 07:46 michael_d Assigned To  => uClibc
11-07-08 15:19 michael_d Note Added: 0015254
11-07-08 15:19 michael_d File Added: uClibc-0.9.30-rc3-nomaxwidth.diff
11-09-08 05:20 bernhardf Note Added: 0015304


Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker