Customizing SMF > SMF Coding Discussion

Show Attachments as KB, MB, GB ??

<< < (3/3)

MrPhil:
That's exactly what I was saying (or trying to say). The internal representation is usually a standard hardware integer size (char, short, long, even long long), with the number of displayed digits meaning that the returned (or inserted) value might be truncated in some way. AFAIK, this also applies to program use of the value, not just command line use -- does anyone have documentation to the contrary? It's hard to believe that MySQL (or any other SQL implementation) would truncate or round down to N digits for the command line but not for API use. Note that there are DECIMAL fields which may be stored as a string (of a given length) of ASCII digits, but that is a separate data type from "int".

Arantor:
Nope, the returned value is not truncated in any way when you're using a non command line client. I can't find any documentation on this but a simple test would be to create a tinyint(1) column then try storing 100 in it and seeing what you get back. Certainly on MySQL 5.0 and 5.1 this returns 100 as expected when using something like phpMyAdmin or the PHP interface.

Iomega0318:

--- Quote from: MrPhil on May 03, 2012, 05:58:11 PM ---You're saying that 45316444 bytes shows as 44254.34 kB and 44.2 MB? Are you sure it's not showing 43.22 MB? Remember, bytes/1024 --> kB, kB/1024 --> MB. Use 1000 if you want kiB and MiB. Where do you get 442.54 MB from?

To show GB (can your server even allow file uploads that size?):

--- Code: ---'size' => $attachment['filesize']>=1073741824
               ? round($attachment['filesize']/1073741824, 2) . ' GB'
               :  $attachment['filesize']>=1048576
                  ? round($attachment['filesize']/1048576, 2) . ' MB'
                  : $attachment['filesize']>=1024
                    ?  round($attachment['filesize']/1024, 2) . ' kB'
                    : $attachment['filesize'] . ' B',

--- End code ---
or

--- Code: ---'size' => $attachment['filesize']>=1000000000
               ? round($attachment['filesize']/1000000000, 2) . ' GiB'
               :  $attachment['filesize']>1000000
                  ? round($attachment['filesize']/1000000, 2) . ' MiB'
                  : $attachment['filesize']>1000
                    ?  round($attachment['filesize']/1000, 2) . ' kiB'
                    : $attachment['filesize'] . ' B',

--- End code ---

--- End quote ---
Was just saying if I use your code it does not work, was wondering why.

If I use the original code:

--- Code: --- 'size' => $attachment['filesize']>1048576 ? round($attachment['filesize']/1048576,2) . ' MB' : ($attachment['filesize']>1024 ? round($attachment['filesize']/1024,2) . ' KB' : $attachment['filesize'] . ' B'),
--- End code ---
it works fine, for example I uploaded a file and changed the database size to "999999999" it now shows up as 953.67 MB

But I was also wanting to convert even larger files to show as GB right now if it's a GB or over it just shows as 4096 MB.

..................................................

MrPhil:
4294967295 is 2^32-1, the maximum 32 bit unsigned integer, which has 10 digits if my eyes don't deceive me. 9999999999 exceeds that internal limit (even though it's still 10 digits) and is likely to cause an error.

I don't know why my code wouldn't work for you, unless your original $attachment['filesize'] is not a 32 bit or smaller integer. Is it a decimal value (floating point)? 1073741824 should fit comfortably within any int or bigint (32 or 64 bit, signed or unsigned). The comparison is done by subtracting one number from the other, so that should work OK. Possibly to do the division, it's converting the values to floating point first, and you're losing enough precision to cause a problem, although the result should be of the correct magnitude:  1100000000/1073741824 might be handled as 1.1E+09/1.07374E+09, but that should still be in the ballpark of 1.02 (GB). I'll have to play around with it a bit, and will post any news here.

Update: OK, add some ( ) as shown in the edited post above. PHP has some peculiar precedence rules!

I read up on the MySQL data types, and it appears that the length, e.g.,  (10) is ignored except when you have ZEROFILL on to left pad with 0's out to the given length for command line display purposes. It is not supposed to affect the actual value in either command line or via API. It's not clear whether a ZEROFILL'd value exceeding the given width simply displays at the needed width (exceeding the given field width); nor is it clear what happens if a signed integer is negative (the use of width 11 leads me to suspect that an extra digit is needed for the minus sign).

Iomega0318:

--- Quote from: MrPhil on May 04, 2012, 01:03:27 PM ---Update: OK, add some ( ) as shown in the edited post above. PHP has some peculiar precedence rules!
--- End quote ---
Awesome, that did it thank you!

Navigation

[0] Message Index

[*] Previous page

Go to full version