BusyBox Bug and Patch Tracking
BusyBox
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
0000802 [BusyBox] Other major always 03-27-06 21:43 04-12-06 04:48
Reporter mbizon View Status public  
Assigned To BusyBox
Priority normal Resolution fixed  
Status closed   Product Version 1.01
Summary 0000802: 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.
Additional Information
Attached Files

- Relationships

- Notes
(0001199)
mbizon
03-27-06 21:49

 Oops, I meant "built _without_ large file support", st_size is 4 bytes.
 
(0001200)
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.
 
(0001267)
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 !
 
(0001268)
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...
 
(0001270)
bernhardf
04-12-06 01:05

 Fixed on trunk as r14831.
Scheduled to be checked into 1_1_stable in a few days.
 
(0001271)
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.
 
(0001272)
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.
 
(0001275)
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.
 
(0001276)
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
^^^^^^^^^^^^^^^^^
 
(0001277)
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?
 
(0001278)
vodz
04-12-06 04:48

 Ok. Excuse me. I forgoten last sync with SVN.

I think, the stat applet is not optimal for non-LFS, have strange strncat() code without decrement buffsize...
 

- 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
04-12-06 04:48 vodz Note Added: 0001278
04-12-06 04:48 vodz Status feedback => closed
04-12-06 04:48 vodz Resolution reopened => fixed
04-12-06 04:48 vodz Description Updated

Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker