Replacement code for the format_size function

Please attach a patch in -up format before setting cnr.. Thanks.

The case for SI is wrong. The SI defines k=kilo=1000 (see http://en.wikipedia.org/wiki/SI_prefix#List_of_SI_prefixes). The KiB, MiB units are defined in IEC 60027-2 (http://en.wikipedia.org/wiki/Binary_prefix#IEC_standard_prefixes) and define 1KiB=1024 Byte.

I've attached a patch without the bits and SI code, but as close to the existing code as possible.

It adds support for 'KiB', 'MiB', 'GiB', 'TiB', 'PiB', 'EiB', 'ZiB' and 'YiB' using the correct naming schema as defined in http://en.wikipedia.org/wiki/Binary_prefix#IEC_standard_prefixes

Edit: removed 'B' from the list, as it is handled by the first if statement...

I know that technically, one has to use KiB and MiB but in practice, people don't know what these stand for (unless you have a CS degree). I'd prefer to stick with MB instead of MiB.

How about using units of 1000 bytes as a kilobyte (KB) then? That would be complient to the SI prefixes: http://en.wikipedia.org/wiki/SI_prefixes#List_of_SI_prefixes and thus not a 'lie'... ;)

reset patch to 'code needs review'...

I'm OK with the patch in #5 but it could use a SimpleTest ...

After running the following test, I found 2 issues with my patch...

1: yottabytes don't fit in a 32-bit integer ;)
2: there is a bug in locale_get_plural() wich uses $langcode = NULL as index in line 422: $locale_formula[$langcode] = $language_list[$langcode]->formula;

The test:

$test_sizes = array(
  '1 byte' =>      '1', // byte
  '1 KB' =>        '1'.'000', // kilobyte
  '1 MB' =>        '1'.'000'.'000', // megabyte
  '1 GB' =>        '1'.'000'.'000'.'000', // gigabyte
  '1 TB' =>        '1'.'000'.'000'.'000'.'000', // terabyte
  '1 PB' =>        '1'.'000'.'000'.'000'.'000'.'000', // petabyte
  '1 EB' =>        '1'.'000'.'000'.'000'.'000'.'000'.'000', // exabyte
  '1 ZB' =>        '1'.'000'.'000'.'000'.'000'.'000'.'000'.'000', // zettabyte
  '1 YB' =>        '1'.'000'.'000'.'000'.'000'.'000'.'000'.'000'.'000', // yottabyte
  '2 bytes' =>     '2', // bytes
  '3.62 MB' =>     '3'.'623'.'651', // megabytes
  '67.23 PB' =>   '67'.'234'.'178'.'751'.'368'.'124', // petabytes
  '235.35 YB' => '235'.'346'.'823'.'821'.'125'.'814'.'962'.'843'.'827', // yottabyte
);
foreach ($test_sizes as $expected => $size) {
  $this->assertTrue(
    ($result = format_size($size, NULL)) == $expected,
    "format_size(): '". $expected ."' == '". $result ."'. %s"
  );
}

Edit: removed attached patch to prevent confusion

I've just created a separate issue for issue 2 in comment #8: http://drupal.org/node/263259

Hum. The handling of file sizes as strings is ugly. Do we really need to support sizes up to yottabytes?

The maximum value of a signed 32-bit integer is 2147483647, which is equal to 2.15 GB.

Support up to yottabyte is probably a bit too much, but it comes for free with this function. I'd guess support of terabyte is quite reasonable these days...

We @ madcap are working on a video platform capable of handling multiple terabytes of data, hence this function enhancement. Filesize is retrieved from a SUM() function in mysql and fetched as a string, because of the limit of 32-bit integers as mentioned above.

Why not treating everything as a float instead? We just don't need arbitrary precision here.

You're absolutely right! ;)

I've just run the test code below both a 32-bit and a 64-bit platform and it passed without any problems using the non-string code as posted in comment #5. Integers larger than 2147483647 are automatically casted into a float on a 32-bit platform and the code in comment #5 does not have a problem with that...

$test_sizes = array(
  '1 byte' =>    1, // byte
  '1 KB' =>      1000, // kilobyte
  '1 MB' =>      1000000, // megabyte
  '1 GB' =>      1000000000, // gigabyte
  '1 TB' =>      1000000000000, // terabyte
  '1 PB' =>      1000000000000000, // petabyte
  '1 EB' =>      1000000000000000000, // exabyte
  '1 ZB' =>      1000000000000000000000, // zettabyte
  '1 YB' =>      1000000000000000000000000, // yottabyte
  '2 bytes' =>   2, // bytes
  '3.62 MB' =>   3623651, // megabytes
  '67.23 PB' =>  67234178751368124, // petabytes
  '235.35 YB' => 235346823821125814962843827, // yottabyte
);
foreach ($test_sizes as $expected => $size) {
  $this->assertTrue(
    ($result = format_size($size, NULL)) == $expected,
    "format_size(): '". $expected ."' == '". $result ."'. %s"
  );
}

If no-one has any other objections, can this be committed to D7?

Patch @ comment #5: http://drupal.org/node/151902#comment-858506

-tnx!-

Harold.

Dries: I'm OK with the patch in #5 but it could use a SimpleTest ...

Simpletest code in comment #13...

The way we use strings to do this is, in fact, ugly. I'd like to see us brainstorm some more about something that is a bit more elegant.

Also, please add the simpletest code as a patch. We commit these to core as well nowadays.

@Dries: The brainstorming is already done. The patch in #5 does not use strings at all, but floats.

Please review the attached patch wich will create a 'common.test' file in which the test for format_size() resides...

The patch for the format_size() function can be found at comment #5.

Off topic: I've changed my username from Harold@Madcap to MadHarold, since IRC doesn't allow '@' in a username...

I've updated format_size() to never show 1000 'whatevers'. I've also added the following test to prove it! ;)

'1 MB'      => 999999, // 1 MB (not 1000 kilobyte!)

Edit:
Removed the 2 patches in favor of the single patch attached below...

Replaced the above patches with a single one, diffed from the root of the Drupal install...

This single patch includes the creation of the common.test file.

Calculations should be in Binary or Decimal (SI)?

Byte
http://en.wikipedia.org/wiki/Byte

@coupet: Dries said that using decimal(1000) calculations would be best. Using binary(1024) calculations would force the output to use KiB, MiB, etc and users would be confused by that...

Using a mix of binary(1024) and KB, MB etc would be 'lying'... :)

Test passes fine and I think it addresses Dries' questions, bumping this to critical as well since it introduces common.test - and a lack of common.test is blocking at least 3-4 patches elsewhere in the queue.

Committed to CVS HEAD. Thanks folks. :-)

Pleae make sure that "KB", "MB", ... are translatable. While they are identical to the English version in most cases, Germans usually use "kB" instead of "KB".

@kkaefer: good catch! I've created a separate issue (+patch) for the missing t() call in http://drupal.org/node/268477

I'll leave this one closed, but I want to add that I've created a new patch for format_size() which can be found here: http://drupal.org/node/267883#comment-1095221