[uClibc 0001884]: printf() field-width limit is unacceptable

bugs at busybox.net bugs at busybox.net
Fri Nov 7 23:19:45 UTC 2008


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=1884 
====================================================================== 
Reported By:                michael_d
Assigned To:                uClibc
====================================================================== 
Project:                    uClibc
Issue ID:                   1884
Category:                   Stdio
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             01-04-2008 07:46 PST
Last Modified:              11-07-2008 15:19 PST
====================================================================== 
Summary:                    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
http://busybox.net/bugs/view.php?id=1869.
====================================================================== 

---------------------------------------------------------------------- 
 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. 

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                          
======================================================================




More information about the uClibc-cvs mailing list