[BusyBox 0000802]: stat shows bogus information for 64 bits values

bugs at busybox.net bugs at busybox.net
Wed Apr 12 11:15:48 UTC 2006


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=802 
====================================================================== 
Reported By:                mbizon
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   802
Category:                   Other
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
====================================================================== 
Date Submitted:             03-27-2006 21:43 PST
Last Modified:              04-12-2006 04:15 PDT
====================================================================== 
Summary:                    stat shows bogus information for 64 bits values
Description: 

stat uses %lu format on (maybe) 64 bits values casted to uintmax_t
(st_size for example).

This prints bogus values on my system where uintmax_t is 8 bytes wide.

mips32 le
gcc version 4.0.2.
uclibc 0.9.28 built with large file support.

====================================================================== 

---------------------------------------------------------------------- 
 mbizon - 03-27-06 21:49  
---------------------------------------------------------------------- 
Oops, I meant "built _without_ large file support", st_size is 4 bytes. 

---------------------------------------------------------------------- 
 anemo - 03-27-06 23:59  
---------------------------------------------------------------------- 
The "j" modifier can be used to print intmax_t/uintmax_t.
I just sent a patch to busybox ML. 

---------------------------------------------------------------------- 
 mbizon - 04-11-06 17:55  
---------------------------------------------------------------------- 
Is it commit 14755 ?

It has no effect for me, there are other places where intmax_t is used
that have
not been changed to the right modifier (in statfs and in stat with
CONFIG_FEATURE_STAT_FORMAT).

Thanks ! 

---------------------------------------------------------------------- 
 anemo - 04-11-06 18:29  
---------------------------------------------------------------------- 
No.  My patch is
http://www.busybox.net/lists/busybox/2006-March/019760.html
The commit 14755 is incomplete.
I'll send to busybox ML again... 

---------------------------------------------------------------------- 
 bernhardf - 04-12-06 01:05  
---------------------------------------------------------------------- 
Fixed on trunk as r14831.
Scheduled to be checked into 1_1_stable in a few days. 

---------------------------------------------------------------------- 
 vodz - 04-12-06 02:02  
---------------------------------------------------------------------- 
Do not close please.
The original (firt issue) problem present.
st_size is not uintmax_t (32 bit), is it off_t and may be
64bit for CONFIG_LFS. 

---------------------------------------------------------------------- 
 bernhardf - 04-12-06 02:47  
---------------------------------------------------------------------- 
I overread this, sorry.

So for off_t should we use PRI[udx..]64 or %z or %L or ..?
I guess we do not care about 128bit arches. 

---------------------------------------------------------------------- 
 anemo - 04-12-06 03:09  
---------------------------------------------------------------------- 
uintmax_t must be _largest_ integer type, so I suppose printf("%ju",
(uintmax_t)st_size) should be safe even if st_size was 64bit. 

---------------------------------------------------------------------- 
 vodz - 04-12-06 03:20  
---------------------------------------------------------------------- 
> uintmax_t must be _largest_ integer type, so I suppose printf("%ju",
(uintmax_t)st_size) should be safe even if st_size was 64bit.

uintmax_t is register size. Not file size.
Why not tested?

$ busybox ls -lh large
-rw-r--r--  1 dzo root 5.0G Apr 12 13:33 large
^^^^^^^^^^^^^^^^^^^^^^^^^^^

$ busybox stat large
Size: 1073741824      Blocks: 4198432    IO Block: 4096   regular file
^^^^^^^^^^^^^^^^^ 

---------------------------------------------------------------------- 
 anemo - 04-12-06 04:15  
---------------------------------------------------------------------- 
I tested on my platform (mipsel + glibc, LFS enabled).
vodz, what is your platform?  LFS enabled?  glibc or uClibc? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-27-06 21:43  mbizon         New Issue                                    
03-27-06 21:43  mbizon         Status                   new => assigned     
03-27-06 21:43  mbizon         Assigned To               => BusyBox         
03-27-06 21:49  mbizon         Note Added: 0001199                          
03-27-06 23:59  anemo          Note Added: 0001200                          
04-11-06 17:55  mbizon         Note Added: 0001267                          
04-11-06 18:29  anemo          Note Added: 0001268                          
04-12-06 01:05  bernhardf      Status                   assigned => closed  
04-12-06 01:05  bernhardf      Note Added: 0001270                          
04-12-06 01:05  bernhardf      Resolution               open => fixed       
04-12-06 01:05  bernhardf      Fixed in Version          => svn             
04-12-06 02:02  vodz           Status                   closed => feedback  
04-12-06 02:02  vodz           Resolution               fixed => reopened   
04-12-06 02:02  vodz           Note Added: 0001271                          
04-12-06 02:47  bernhardf      Note Added: 0001272                          
04-12-06 03:09  anemo          Note Added: 0001275                          
04-12-06 03:20  vodz           Note Added: 0001276                          
04-12-06 04:15  anemo          Note Added: 0001277                          
======================================================================




More information about the busybox-cvs mailing list