57240 2003-04-15 01:56:37 +0000 Display file size in kibibyte, mebibyte... ? 2022-05-22 12:34:55 +0000 1 1 2 Applications konqueror general unspecified Mandrake RPMs Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=364321 NOR wishlist --- 453853 453854 454182 1 lcn konqueror-bugs-null bluedzins f.de.kruijf faure ivan.tefalco john js.lebacq kde lars.dieckow majewsky meta mpyne samjnaa xeriouxi 201 oldest_to_newest 128604 0 lcn 2003-04-15 01:56:38 +0000 Version: (using KDE KDE 3.1.1) Installed from: Mandrake RPMs Has Konkeror started to display file size in kibibyte (KiB), mebibyte (Mib)... ? 177577 1 smt 2003-11-18 00:32:13 +0000 No; they aren't commonly used. When they are, we'll probably switch to them, but I highly doubt that's gonna happen any time soon. 206746 2 binner 2004-02-17 17:11:27 +0000 *** Bug 75304 has been marked as a duplicate of this bug. *** 207012 3 florent 2004-02-18 09:10:21 +0000 KDE follow standards and KiBs are standard from the SI. So KDE should follow SI. 207047 4 js.lebacq 2004-02-18 10:53:13 +0000 I agree with you. Moreover, because that bug report is a wish, I want to make the following suggestion: the user could have the possibility to choose between prefixes for binary multiples (KiB, MiB, GiB, etc...) and prefixes for decimal multiples (KB, MB, GB, etc...). Moreover, the software could make pretext of that choose for explaining the difference to the user. Also, I must disagree with one point: KiBs are not standard from the SI. Actually, the standard from SI is: 1 KB = (10^3)^1 B = 10^3 B = 1 000 Bytes 1 MB = (10^3)^2 B = 10^6 B = 1 000 000 Bytes 1 GB = (10^3)^3 B = 10^9 B = 1 000 000 000 Bytes etc... (ha, decimal multiples are so easy :)) That's why IEC (International Electrotechnical Commission) approved as an IEC International Standard names and symbols for prefixes for binary multiples: 1 KiB = (2^10)^1 B = 2^10 B = 1 024 Bytes 1 MiB = (2^10)^2 B = 2^20 B = 1 048 576 Bytes 1 GiB = (2^10)^3 B = 2^30 B = 1 073 741 824 Bytes etc... So, we don't use a SI standard when we use KiB ("only" an IEC standard), but when we say "1 KB=1024 Bytes", we totally disagree with SI, wich says 1 K = 1000, for all units (meter, bytes, etc...). It's a reason too to offer KiB and (real, in the SI mean) KB to the user, sothat the user can use an SI standard. I want to point out that the introduction of the binary prefixes answers real difficulties: http://www.iec.ch/zone/si/si_bytes.htm http://physics.nist.gov/cuu/Units/binary.html 223066 5 kfl 2004-04-12 13:27:05 +0000 the current behavior is simply wrong, if you look at the standards. Eigher leave the current calculation and write "KiB", "MiB".. as units or calculate them with 1000B = 1 KB 231326 6 lcn 2004-05-11 19:01:36 +0000 A little remind : You should write kilobyte as kB instead of KB. Prefix for kilo is k, kilometre is written as km. But for kibibyte, kibibyte is written as KiB. http://en.wikipedia.org/wiki/SI_prefix (english) http://www-rocq.inria.fr/qui/Philippe.Deschamp/RETIF/gibi.html (french) 234703 7 kde 2004-05-20 19:10:34 +0000 I would like to see Konqi (all of KDE, really) adhere to the IEC standard. IMO, Konqi should default to using binary units, but it should be a configuration option. Also, Konqi could display both base-2 and base-10 units in the status bar, tool tips, etc., to help people understand the differences. While there are undoubtedly people on both sides of this argument, I think it should be the users who decide whether to adhere to the standard or not, rather than the developers. If the developers allow both options, rather than only their personal choice, I think the freedom (libre) aspect of Free Software would be best served. Thanks for your consideration. Regards, Mark 240537 8 danielb 2004-06-11 00:44:47 +0000 In general the most common standard should be followed with the correct notations. If several standards are common, let the user chose. 299921 9 gschintgen 2005-01-05 17:34:46 +0000 IMHO the only thing that's not okay is to write MB and mean MiB (or vice versa), but unfortunately that's exactly what konqueror does :-/ It's already bad enough that a "256 MB" USB stick has in fact 256000 KiB which is neither 256 MB nor 256 MiB. Konqueror just adds to the confusion by mixing both types of units. 299933 10 kde 2005-01-05 17:50:11 +0000 If you know places where Konqueror do not follow defacto standard of k=2^10, M=2^20 and G=2^30 then please tell us so be can be consist about breaking the IEC "standard" (hardly a standard if noone uses it). 299941 11 gschintgen 2005-01-05 18:08:24 +0000 On Wednesday 05 January 2005 17:50, Allan Sandfeld wrote: > If you know places where Konqueror do not follow defacto standard of Well, I know of exactly two standards and konqueror doesn't follow either of them. > k=2^10, M=2^20 and G=2^30 then please tell us so be can be consist about > breaking the IEC "standard" (hardly a standard if noone uses it). AFAIK, k was never 2^10, you probably meant K. The units(7) man page is quite interesting. I don't know about yours, but my kernel (Linux) prints this when booting: hda: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63, UDMA(66) It couldn't be clearer. I really don't want to start a flamewar about this, there's just huge potential for confusion when in fact everything's quite simple: it always comes down to the fact whether base 2 or base 10 is used. Unfortunately _both_ are used heavily in computing. So, the only way to avoid unnecessary confusion is to have two distinct names for two distinct concepts. In my opinion the best way is to make it configurable whether KDE apps use base 2 or base 10, but they should never mix both types of units (as is currently done). I don't even care if base 2 or base 10 is default. Why would you object to have base 2 computations together with the symbols MiB, GiB, etc.? Kind regards Gilles 299948 12 kde 2005-01-05 18:21:50 +0000 I object to MiB and GiB because they are not well known and can confuse users. (Most users only experience problems with the two standards when they realize their 120Gbyte disk cannot hold 120Gbyte, and that is a marketing scam) I think KDE is pretty consistent as it is, and consistent with other operating systems as well. Using 10 based everywhere, except when measuring quantities of bytes where 2-based is the norm. However I would not object to an option of showing byte quantities in base 10, as long as it is off by default. 299959 13 gschintgen 2005-01-05 18:39:11 +0000 On Wednesday 05 January 2005 18:21, Allan Sandfeld wrote: > I object to MiB and GiB because they are not well known and can confuse > users. What do "typical end users" know anyways? Ask them what the meaning of MB is in the case of - a hard disk - a floppy - a CD-R - a USB flash drive. - RAM They're already confused, so where's the difference? (Except perhaps that now they know they're confused ;-)) If you find MiB and GiB objectionable, why not change the computation to base 10. This is less silly as it may seem at first: - Who cares about the exact size of a file? It's the order of magnitude that's important. (After all that's the reason the size is displayed in MBs or MiBs and not in bytes.) - When one has to see whether a file fits onto a storage medium it all depends of the device class anyway (see above). So it's always necessary to plug the device and compare the available space to the file size, using the same unit, being it base 2 or 10. - With base 10 as default, it's completely okay to call it "megabytes" and the "confusing" name "MiB" isn't used. Not that I would be particularly in favour of switching to base 10. As I already stated, I don't care, as long as the correct names are used. 317662 14 meta 2005-02-23 22:58:33 +0000 I agree strongly with Gilles Schintgen. Konqueror should either show KiB and MiB and label them KiB and MiB, or it should show KB and MB and label them KB and MB. I don't care which option is the default, I just want KDE to give correct output. Currently it shows KiB and MiB but labels them KB and MB, which is just wrong. 327026 15 thiago 2005-03-23 00:28:06 +0000 *** Bug 102196 has been marked as a duplicate of this bug. *** 379981 16 12915 kde 2005-10-08 02:46:05 +0000 Created attachment 12915 Implement SI and IEC standard byte prefixes It's been almost two years since this was originally requested, and it still isn't implemented. My _perception_ is that the developers refuse to provide users with the option of having Konqueror, and the rest of KDE, give accurate and standards-compliant information. This makes no sense to me. We do everything else to a standard (where possible), regardless of how screwed up other systems may do it. I understand that the developers wouldn't want to _force_ such a change on the users, but IMO it is reasonable to expect that they allow us at least the _option_ of complying with standards. With KDE 3.5 getting closer to being out-the-door, KDE 4 should be getting more and more attention from developers. With all the other library changes being made, now seems like a perfect time to fix this issue for KDE 4. I have attached a patch that fixes KIO by implementing functions for both SI-standard prefixes and the IEC Binary Prefixes. A mechanism should still be developed to allow users the option of which function to default to, even if that option doesn't have a GUI anywhere. Since this is my first patch ever to KDE, I am sure there will have to be implemented differently, but I do hope this will inspire a proper solution to this issue. Thanks, Mark Taff 380125 17 12919 kde 2005-10-08 23:22:53 +0000 Created attachment 12919 Updated IEC Prefix Patch This is an updated patch. It fixes a tab problem. It also defaults to using the IEC binary prefixes with binary math, as that is the closest to existing behavior. It still has functions for both binary and base 10, so developers could specify one way or the other when needed. 380269 18 faure 2005-10-09 20:04:48 +0000 Thanks for the patch; however I'm not sure if we should let applications decide which unit to use; shouldn't we use only one, and consistently? I think there should be only one "convert" method, and it should either always use kB/MB/GB, or always kiB/MiB/GiB, or use a hidden config entry to decide (I don't think most people care, so no GUI checkbox). For now I'd simply keep the existing conversions and change the labels to be correct. But it's too late in the 3.5 branch already (message freeze since September 5th!). 380275 19 faure 2005-10-09 20:11:02 +0000 SVN commit 468927 by dfaure: Use the correct units for the calculation that we make: 1024 B is 1 KiB, not "1 KB". IMHO this resolves 57240, but let's see if anyone really wants kB support too... CCBUG: 57240 Can I backport it to the 3.5 branch even though breaks the message freeze? CCMAIL: kde-i18n-doc@kde.org M +20 -8 global.cpp --- trunk/KDE/kdelibs/kio/kio/global.cpp #468926:468927 @@ -45,30 +45,42 @@ #include <volmgt.h> #endif +// If someone wants the SI-standard prefixes kB/MB/GB/TB, I would recommend +// a hidden kconfig option and getting the code from #57240 into the same +// method, so that all KDE apps use the same unit, instead of letting each app decide. + KIO_EXPORT QString KIO::convertSize( KIO::filesize_t size ) { + // Per IEC 60027-2 + + // Binary prefixes + //Tebi-byte TiB 2^40 1,099,511,627,776 bytes + //Gibi-byte GiB 2^30 1,073,741,824 bytes + //Mebi-byte MiB 2^20 1,048,576 bytes + //Kibi-byte KiB 2^10 1,024 bytes + double fsize = size; QString s; - // Giga-byte + // Gibi-byte if ( size >= 1073741824 ) { fsize /= 1073741824.0; - if ( fsize > 1024 ) // Tera-byte - s = i18n( "%1 TB" ).arg( KGlobal::locale()->formatNumber(fsize / 1024.0, 1)); + if ( fsize > 1024 ) // Tebi-byte + s = i18n( "%1 TiB" ).arg( KGlobal::locale()->formatNumber(fsize / 1024.0, 1)); else - s = i18n( "%1 GB" ).arg( KGlobal::locale()->formatNumber(fsize, 1)); + s = i18n( "%1 GiB" ).arg( KGlobal::locale()->formatNumber(fsize, 1)); } - // Mega-byte + // Mebi-byte else if ( size >= 1048576 ) { fsize /= 1048576.0; - s = i18n( "%1 MB" ).arg( KGlobal::locale()->formatNumber(fsize, 1)); + s = i18n( "%1 MiB" ).arg( KGlobal::locale()->formatNumber(fsize, 1)); } - // Kilo-byte + // Kibi-byte else if ( size >= 1024 ) { fsize /= 1024.0; - s = i18n( "%1 KB" ).arg( KGlobal::locale()->formatNumber(fsize, 1)); + s = i18n( "%1 KiB" ).arg( KGlobal::locale()->formatNumber(fsize, 1)); } // Just byte else if ( size > 0 ) 380299 20 nicolasg 2005-10-09 21:19:28 +0000 On Sunday 09 October 2005 20:10, David Faure wrote: > SVN commit 468927 by dfaure: > > Use the correct units for the calculation that we make: 1024 B is 1 KiB, > not "1 KB". IMHO this resolves 57240, but let's see if anyone really wants > kB support too... CCBUG: 57240 Sorry but I find it curious that on one side we try to increase usability for new users and on on the other, we introduce now units that are supposed to be for experts only, as far as I know. > > Can I backport it to the 3.5 branch even though breaks the message freeze? No backport, please. KDE 3 has always used the legacy/historical abbreviations and should keep so, especially as we are in message freeze for KDE 3.5. If it was supposed to be in any KDE 3.x, it could have been done at the time of the discussion on kde-core-devel in 2002: http://lists.kde.org/?t=103245396300004&r=1&w=2 Have a nice day! > CCMAIL: kde-i18n-doc@kde.org > > > M +20 -8 global.cpp > > > --- trunk/KDE/kdelibs/kio/kio/global.cpp #468926:468927 > @@ -45,30 +45,42 @@ > #include <volmgt.h> > #endif > > +// If someone wants the SI-standard prefixes kB/MB/GB/TB, I would > recommend +// a hidden kconfig option and getting the code from #57240 into > the same +// method, so that all KDE apps use the same unit, instead of > letting each app decide. + > KIO_EXPORT QString KIO::convertSize( KIO::filesize_t size ) > { > + // Per IEC 60027-2 > + > + // Binary prefixes > + //Tebi-byte TiB 2^40 1,099,511,627,776 > bytes + //Gibi-byte GiB 2^30 1,073,741,824 > bytes + //Mebi-byte MiB 2^20 1,048,576 bytes > + //Kibi-byte KiB 2^10 1,024 bytes > + > double fsize = size; > QString s; > - // Giga-byte > + // Gibi-byte > if ( size >= 1073741824 ) > { > fsize /= 1073741824.0; > - if ( fsize > 1024 ) // Tera-byte > - s = i18n( "%1 TB" ).arg( KGlobal::locale()->formatNumber(fsize > / 1024.0, 1)); + if ( fsize > 1024 ) // Tebi-byte > + s = i18n( "%1 TiB" ).arg( > KGlobal::locale()->formatNumber(fsize / 1024.0, 1)); else > - s = i18n( "%1 GB" ).arg( > KGlobal::locale()->formatNumber(fsize, 1)); + s = i18n( "%1 GiB" > ).arg( KGlobal::locale()->formatNumber(fsize, 1)); } > - // Mega-byte > + // Mebi-byte > else if ( size >= 1048576 ) > { > fsize /= 1048576.0; > - s = i18n( "%1 MB" ).arg( KGlobal::locale()->formatNumber(fsize, > 1)); + s = i18n( "%1 MiB" ).arg( > KGlobal::locale()->formatNumber(fsize, 1)); } > - // Kilo-byte > + // Kibi-byte > else if ( size >= 1024 ) > { > fsize /= 1024.0; > - s = i18n( "%1 KB" ).arg( KGlobal::locale()->formatNumber(fsize, > 1)); + s = i18n( "%1 KiB" ).arg( > KGlobal::locale()->formatNumber(fsize, 1)); } > // Just byte > else if ( size > 0 ) 380314 21 faure 2005-10-09 22:02:11 +0000 On Sunday 09 October 2005 21:19, Nicolas Goutte wrote: > Sorry but I find it curious that on one side we try to increase usability for > new users and on on the other, we introduce now units that are supposed to be > for experts only, as far as I know. It will become known to more than experts if we start using the correct units in GUIs, not just in the linux kernel boot message. Chicken and egg problem, let's make the first egg to solve the problem. > If it was supposed to be in any KDE 3.x, it could have been done at the time > of the discussion on kde-core-devel in 2002. No time machine, sorry. Also, time had started to make the units more used already, so switching makes more sense now than at the time. 380327 22 kde 2005-10-09 22:43:45 +0000 With this change being made, I would be happy to write some documentation text explaining the differences between SI and binary prefixes, a short history, and how this new standard clears up the confusion. I presume we need a page for Konqi's handbook, and some generic what's this text/code that could be added to all apps who use these units without using KIO. Any other places where there might need to be some documentation? As for the SI-standard prefixes, I believe they are used for some aspects of computing, such as transmission line speed. We may not need them in KIO, but perhaps in some other part of KDE Libs? 380334 23 faure 2005-10-09 23:06:15 +0000 On Sunday 09 October 2005 22:43, Mark A.Taff wrote: > With this change being made, I would be happy to write some documentation > text explaining the differences between SI and binary prefixes, a short history, > and how this new standard clears up the confusion. Thanks, that would be a good idea. > I presume we need a page for Konqi's handbook Yes. Please send the text (preferrable docbook formatted) to the kde-doc-english mailing-list or to Lauri Watts <lauri@kde.org>. Thanks! 380406 24 faure 2005-10-10 10:00:23 +0000 On Monday 10 October 2005 09:44, you wrote: > Am Montag, 10. Oktober 2005 00:48 schrieb Federico Zenith: > > I do not agree if you mean that we should continue using "kilo" for 1024 > > and similar ones for "mega" and "giga", this is simply wrong. I agree if > > you mean we should keep these prefixes and correct their actual values to > > 10^3, 10^6, and 10^9. I've been thinking about that after my commit - this might be a better solution indeed. Only a fraction of computer users know that 1 KiB = 1024 B, whereas everyone knows that 1 kB = 1000B just like 1 kg = 1000g. > I don't really think this issue should be discussed on the translators list, > rather on some usability list. Generally I agree though - I'm pretty tired > of my hard drive having 40GB, but only having place for 37 files that > konqueror displays as 1GB. Does 40G for the harddrive mean 40*1000000 bytes? Then using GB (decimal) for the files would be a good idea indeed. 380415 25 gschintgen 2005-10-10 11:32:04 +0000 > Does 40G for the harddrive mean 40*1000000 bytes? Then using GB (decimal) > for the files would be a good idea indeed. Yes, but unfortunately hard disks are not the only available storage media. And the size of one "MB" depends on the category (floppy, USB stick, CD, DVD, HDD). That's why it's so important to get some consistency in the use of MB and MiB. 380430 26 germain 2005-10-10 13:15:44 +0000 > Only a fraction of computer users know that 1 KiB = 1024 B, > whereas everyone knows that 1 kB = 1000B just like 1 kg = 1000g. I fully agree with that view... please, let's just use base 10 and keep iB units in the lab... 380492 27 thiago 2005-10-10 17:36:14 +0000 No, let's not do that, please. No one uses decimal units except harddrive manufacturers. If Konqueror suddenly starts displaying ISO images as 734 MB, people will be confused. The fact that end users don't know 1 kilobyte (I refuse to name it kebibyte) = 1024 bytes doesn't change anything. However we name them, we should use powers of 2. I would prefer nothing be changed, though. 380528 28 kde 2005-10-10 21:25:25 +0000 Gilles is right on target. It is very important to set/keep kB = 1000 and kiB = 1024 to avoid confusion. As it is now, when you see kB, MB, etc, you have no way of knowing whether they mean base 2 or base 10 besides looking at the actual byte count. Germain is right that it seems natural for non-geeks that kilo, mega, etc keep their SI meanings. Some people will be strongly resistant to any change, like Thiago refusing to call 1024 bytes a kebibyte, despite the IEC and IEEE standards. Thiago argues for the status quo, which is _completely_ incorrect. Either switching completely to SI or completely to Binary are equally correct solutions. I prefer the binary IEC solution for most things, as it maintains the computer heritage of using base 2 math, and porting existing apps is trivial. However, we still need to use the SI prefixes for other computer uses, such as transmission speeds, bus speeds, clock speeds, etc. I submit most users aren't going to care whether kB=1000 or if kB=1024. Those that do care about it, should be given the correct info, i.e. kilo=1000 (like with line speed) and kebi=1024 (like in file sizes). I like David's commit as is, though I could support a config-file-only option to choose between SI and IEC. Regards. Mark 380553 29 kde 2005-10-10 23:00:52 +0000 You are making it unnecessarily confusing bytes are always measured in base 2 kilos/megas except by lying harddisk manufacturers. Bits are measured in base 10 kilo (like in bandwidths). Besides refering to SI means nothing as long as bytes is not a SI unit. kbytes is not a SI unit no matter if k means 1000 or 1024. 380562 30 gschintgen 2005-10-10 23:29:59 +0000 On Monday 10 October 2005 23:00, Allan Sandfeld wrote: > bytes are always measured in base > 2 kilos/megas except by lying harddisk manufacturers. * What about those DVD-5 discs which hold 4.7 "GB"? Guess what, that's 4.7 (decimal) GB or 4.38 gibibytes. (See wikipedia.) * Hmmm, DVDs and CDs are almost the same, aren't they? Surprise, surprise. 1CD = 700 "MB" where "MB" is actually MiB (contrary to DVDs). * What's left? Flash media. Binary? Decimal? Neither! $ df /dev/sdb1 255728 1188 254540 1% /media/sdb1 That's right, in the case of my Cruzer Micro, 1 "MB" equals 1000*1024 bytes (approximately). In other words, its capacity of "256 MB" is actually 250 MiB or 262 MB. Do you still think that everything is just perfectly fine? Kind regards, Gilles 380570 31 kde 2005-10-10 23:52:15 +0000 When we refer to `SI`, we are not alleging that byte is an official SI base, derived, or other unit, but rather we are referring the the SI standard meanings of the base unit multiple prefixes like kilo-, mega-, giga-, etc. According to wikipedia, the hard drive manufacturers aren't lying, though they do seem to be, in some cases, taking advantage of the confusion over the definition of the SI-standard prefixes. Regards, Mark 380596 32 thiago 2005-10-11 04:27:26 +0000 That means there is no definite standard by hardware and component manufacturers. The only standard so far is what programmers use: base 2. So I prefer we stick to it. Whether the unit is "KiB" or "kB" it doesn't really matter for me. How many people did know the "k" should be lowercase anyways? All I ask is that you never write "kebibyte" in full :-) (which would have to be i18n'ed, because "byte" doesn't exist in French, for instance) (but, then again, KiB must be i18n'ed as well, so that's not an argument) What is also the correct way to express "bit"? As "b" or "bit"? I've seen Mb/s and Mbit/s and I would much rather see the latter. 380603 33 kde 2005-10-11 05:00:41 +0000 From my readings, the SI people prefer "bit" instead of "b" as that way it can't be confused with the Bel (B). They do note that for most practical measurements, the deci-bel is used, so it seems they begrudgingly accept "b" as being OK for bit. What about nibble? Unfortunately, I think we shall have to write out "kebibyte" in the same places we would have to write out "kilobyte", such as documentation. Sorry. :-( 380666 34 kfl 2005-10-11 11:10:46 +0000 I don't think, that it's easy to understand, that B and b means something totally different, so we should write "Mbit". This 1000*1024 is somewhere else too: Floppies. They are neigher 1,44MB nor 1,44MiB. They are 1440 KiB. Afaik even hard disks are 1000*1000*1024 Byte = "1 GB" 381419 35 florent 2005-10-14 15:14:55 +0000 Let's add my point of view: For years and years and before computing science, "k" is meaning "thousand". One day a not very rigorous data processing specialist decided to call "kB" a unit of 1024 bytes because 1024 it is almost 1000. It's time to repair this error for multiple reasons. First for the newbies: To increase the comprehension and accessibility of computing. Second to raise ambiguities: The primary error on "k" has produce many ambiguities bitween units in bandwith, floppy, hard disc, RAM... Third again ambiguities: What about "m"? is mB is 1000x1024 or 1024x1024? There is multiple logics. So please repair errors made in the past. No matter of a few computer scientists: "The irreducible Asterix and Obelix". Bring to the world the clarification which it needs. 381422 36 kde 2005-10-14 15:23:01 +0000 Actually kb was invented to mean 1024 bytes. B was original used for bits. But for some logical concerns KB was later used to mean 1024 bytes. m means milli (1/1000) by the way, you are thinking of M which is 1^6. But life is full of mistakes. If we where rational we would use 12-based "decimal" system, the US would use metrics and we would all use Kelvin. Don't wage a holy war on reality, just deal with the ambiguity. 399237 37 holmgren 2005-12-16 23:36:33 +0000 Isn't this bug ready to be closed? My Konqueror shows Kibytes and Mibytes and I'm so happy! Someone had to take the first step and you did! (I hope it's not just in Debian.) Now go metricate the U[SK]. :-) (OK, first fix Gnome.) 400103 38 didier 2005-12-20 00:52:15 +0000 Not solved in Ubuntu's version. Version 3.5.0. 403579 39 olivier_ripoll 2006-01-04 17:27:08 +0000 Sorry to add more noise to this bug, but I think the issue is worth it. Here is my tentative to summarize the situation, and to clarify it for some people who seem very confused. As pointed several times here, more information can be found on Wikipedia[1]. First, which device is using what ? The "power of two" prefix are used in: - RAM - CD The "power of ten" prefix are used in: - hard drives built since at least 2001 - DVD - next generation DVD (HD-DVD and blu-ray) - USB flash memories/drives (my 128 MB usb stick contains 129.366.016 bytes, which in binary units would correspond to 124 megabytes) - memory cards (e.g. a 16 MB memory stick contains 16.138.240 bytes) As of operating systems and desktop environments: The "power of two" prefix are used in: - MS Windows - Gnome - KDE (well, it seems it has changed in recent version) The "power of ten" prefix are used in: - Linux kernel (check dmseg) - Rox, a quite user-friendly desktop using GTK toolkit. I do not know the situation for MacOSX or BSDs. GNU is defaulting to power of two, but at least some of its tools can also use power of ten(*). Historically, there was no convention used on computers in the past. Indeed, the famous 1.44 floppy disk contained 1.44 * 1000 * 1024 bytes, which is quite characteristic of the past confusion. Pretending that there was a clear convention for kilo=1024 is just plain inaccurate. What are the reasons to stay with power of two when displaying files in KDE ? - binary arithmetics is faster than power of ten one. TRUE, but what is the gain... a few micro(milli?)-seconds ? - present code uses power of two. - developers like power of two. What are the reasons to switch to power of tens when displaying files in KDE ? - to be consistent with what is written on the DVD pack, or on the USB key, etc. of the user. - for Aunt Tillie, using powers of ten is much easier than powers of two. - to be consistent with the other units used in the computer, such as the MHz or GHz of the processor which stand for million and billion respectively. Same argument is valid with the MBit/s of network devices/modems or the MFlops/GFlops of the CPU/GPU. Or the refresh rates of the screen in Hz and kHz (line scan frequency). - to remove any source of confusion: when binary system is more useful, the standard proposed by the IEC, (KiB, MiB, GiB etc.) can be used. - to follow the worldwide centuries old standard[2] than nearly everyone has agreed on. A kilogram is 1000 grams. A kilometer is 1000 meters. A GigaHertz is 1 billion Hertz. Why would a GigaByte be 1073741824 Bytes ? - To follow an international standard. After all, Free Software / Open Source has shown its superiority to commercial software when it comes to follows standards, such as CSS, XHTML or PNG. Think about how good KHTML and Gecko are compared to commercial counterparts. Yes it is a political choice, similar to the use of the new open document format in openoffice.org and Koffice. This standard is at least set in the SI[3-6], ISO 31[7] and IEC 60027-2[8] standards. - to be consitent with the most used kernel for KDE users: Linux, which has been following the standards for years. So there are 3 possible alternatives: 1- use kilo/meg/giga/tera prefix and power of 2. This solution creates a confusing state, since there exist two competing definitions for the terms. One widely used, the power of ten, and one marginally used ,the power of 2. 2- use kibi/mebi/gibi prefix and power of two. This solution seems confusing too since they are not widely known prefix. 3- use "power of ten", i.e. plain SI units. This is the most user-friendly solution. It also follows the de-facto industry standard, so the file manager and other programs returned information consistent with the devices. The only reason I see against the power of ten is that the convertion requires more CPU cycles. However, I cannot think of any application where this could result is a visible slowdown of the computer. Notes and references (*) example: "df --si" or "df -H", "ls --si". Additionally, df and ls use MB for 1,000,000 and M alone for 1,048,576 [1] http://en.wikipedia.org/wiki/Binary_prefix [2] According to the following link, kilo was introduced in 1793 and mega in 1874. http://web8.ehost-services.com/cdkaese/metre/prefixes.htm#encyclopaedia [3] http://en.wikipedia.org/wiki/SI [4] http://en.wikipedia.org/wiki/SI_prefix [5] http://physics.nist.gov/cuu/Units/binary.html [6] http://www.bipm.fr/en/si/prefixes.html [7] http://en.wikipedia.org/wiki/ISO_31 [8] http://en.wikipedia.org/wiki/IEC_60027-2 464426 40 kde 2006-08-30 01:30:02 +0000 In reply to oliv I would point out that there is one other option: To allow for both #2 or #3 via a global config option. In that case, I would certainly prefer option #2 set as KDE's default, though I am certain each distro will have their way with that one. Regards, Mark 515807 41 me 2007-03-18 10:22:23 +0000 *** Bug 143142 has been marked as a duplicate of this bug. *** 617047 42 l.lunak 2008-06-28 12:52:09 +0000 *** Bug 131022 has been marked as a duplicate of this bug. *** 617049 43 l.lunak 2008-06-28 12:52:24 +0000 *** Bug 138893 has been marked as a duplicate of this bug. *** 617051 44 l.lunak 2008-06-28 12:52:36 +0000 *** Bug 164299 has been marked as a duplicate of this bug. *** 619514 45 christophe 2008-07-03 01:16:35 +0000 *** Bug 165603 has been marked as a duplicate of this bug. *** 624680 46 lcn 2008-07-14 20:07:04 +0000 In reply In reply to oliv for comment #39. Agreed with comment #40. Option 2 by default. A config option with option 3. A small description in the help. 624691 47 bluedzins 2008-07-14 20:27:35 +0000 I feel like dying species or something :-( I was always taught kilo stand for 1000, Kilo stands for 1024, and it was far from ZX81 times. Even if KiB is more trendy nowadays please provide option to choose suffix (KB/KiB) and meaning of it. I think nowadays beasts that can handle fancy plasmoids can handle one extra call to kdelibs capacity_str(free_space_on_usb()) instead of hardcoding this calculation, The reason for this is: * on one hand do whatever is necessary to do to please weekend users * on the other hand please respect old-timers (I don't felt like 5 minutes ago) so I could still live happily in world of KB/GB and good 2^X scale 196 votes, 47 comments, and two tiny options which could "solve" this once for good I think it is not too much to ask. [ ] use KiB suffix instead of KB [ ] use 10^N instead of 2^X 624695 48 bluedzins 2008-07-14 20:30:53 +0000 PS. The product should be kdelibs, not konqueror, because it would be crazy if each app would use its own settings. 624861 49 lars.dieckow 2008-07-15 08:58:15 +0000 Comment #47, please also read all duplicates before adding comments. The bugzilla janitors here are a quite a zealous bunch and also merge topics that are just related, not exactly identical. These preferences are no good. See bug 131022 for a mock-up that attempts to cover all use cases. 624883 50 bluedzins 2008-07-15 10:01:56 +0000 Why not? It covers all possibilities (sane ones). KiB meaning 1000 KiB meaning 1024 KB meaning 1000 KB meaning 1024 (and of cours the same for GB, MB, TB, PB, and so on) Is there any "system" of calculation missed? The bug mentioned above is wrong, there was not such "system" as G for Giga and k for Kilo at the same base. It was always lowercase (k,m,g...) or uppercase (K,M,G..) not mixed. And for octet, ok, one option more if it is really valid, I didn't hear about Go for capacity, but well, I learn all life :-) 624886 51 bluedzins 2008-07-15 10:07:37 +0000 PS. One more note, I think it is not to debate how many variants are needed, but to cover the most "hot" issues right now. The fact is for sure there one function in kdelibs would can convert number of bytes to proper string, and if those two options will not be enough there could be a further discussion what else is needed. But note -- there will be no more changes in libraries, because you still need to call this capacity_str function. 624995 52 meta 2008-07-15 16:13:08 +0000 "The bug mentioned above is wrong, there was not such "system" as G for Giga and k for Kilo at the same base. It was always lowercase (k,m,g...) or uppercase (K,M,G..) not mixed." What are you talking about? The case of the letters is defined within the SI unit system. Giga (G) is always upper case, kilo (k) is always lower case. The informal use of a capital K for base-2 is where this confusion started. Since everything anyone is likely to want to do with a file size will be base-10 (calculating space left on disk, which is always given in base 10 by manufacturers; calculating upload or download time, since network speeds are always base 10) it makes no sense to provide file sizes in base 2. The only time you'd care about that was if you wanted to calculate whether a file would fit in RAM, and when does anyone ever do that? So the useful option, for average users, is base 10 units, standard SI prefixes. For computer scientists, a checkbox for base-2 and Ki/Mi/Gi should suffice, as they aren't going to panic if they see an unfamiliar prefix, and they ought to have seen the base-2 prefixes by now. Also, since I haven't linked to my article on the subject yet: http://lpar.ath0.com/2008/07/15/si-unit-prefixes-a-plea-for-sanity/ 625000 53 bluedzins 2008-07-15 16:32:23 +0000 Mathew, about mix -- you are right, since I am developer I live in bits world mostly, sorry for that. But about the rest -- not everyone wants base 10. I used KB/MB/GB terms for last 22 years (in 2^X scale) and I don't want to change my thinking just because KDE becomes more "trendy" and uses KiB/GiB and so on. Respect users habits. And I don't get your argumentation -- will those two options hurt you in some way? No? Then let users decide for their own. I don't see any point in narrowing choice if I know right now that it will not suffice. 625214 54 meta 2008-07-15 23:38:08 +0000 It's nothing to do with "trendy", it's to do with accurately and unambiguously reporting file sizes. No matter how much you may wish it wasn't true, the vast majority of things, even in the computer world, are measured in base 10 units--including disk capacity and network speed. Therefore it's simply more useful to provide base 10 by default. (Read my article linked above.) Nobody's suggesting that there shouldn't be an option for base 2, if for some bizarre reason you find that more useful. But base 2 should be indicated correctly, of course. 625362 55 bluedzins 2008-07-16 10:59:24 +0000 > Therefore it's simply more useful to provide base 10 by default. Of course. I totally agree. > Nobody's suggesting that there shouldn't be an option for base 2, > if for some bizarre reason you find that more useful. It is not "bizarre", it is different. Respect other people, please. My only objection was limiting options to either KB for 1000 or KiB for 1024. The scale should be configurable _and_ unit (independently). 625493 56 meta 2008-07-16 15:55:39 +0000 > The scale should be configurable _and_ unit (independently). What rational reason could there be to display kB but indicate KiB? Or to display KiB, but indicate kB? 625504 57 john 2008-07-16 16:10:48 +0000 Seriously, things are standardized (IEC, IEEE etc.). If you use base 10, its kB, if you use base 2, its KiB. KB is unofficial and not standardized. see http://en.wikipedia.org/wiki/Binary_prefix and http://www.annodex.net/cgi-bin/man/man2html?units+7 why do we have institutions for standardization when we don't respect the standards they define. just my 5 cents... ;-) 625509 58 bluedzins 2008-07-16 16:20:05 +0000 You (Mathew) opt for having _mutual exclusive_ two options. Does it really hurt your feeling or something, that you cannot allow people to have non-mutual exclusive two options. Is a crime that I would set it for KB/1024? I don't simply get it. Let me use use my computer the way I used it for 22 years. Mathew, John, standards, your likes and dislikes, I don't really mind if you call 10 bits a byte. It is your free choice. And in return I expect you allow me to use KB/1024 system, ok? Those options will be implemented and I don't see any point in insisting they have to be mutual exclusive. You, your computer, your programs will be no affected by my non-standard information display, I promise :-) 625516 59 faure 2008-07-16 16:30:46 +0000 Well there is such a thing as over-configurability, so no we are not going to add an option for "calling 10 bits a byte", to take your far-fetched example. Similarly, there shouldn't be an option for KB should be there at all, it doesn't make sense. This isn't just about choice (you can use your computer the way you want, just patch kde), it's also about making the world a slightly more sensible place by not propagating ambiguities onto more people. I'm opposed to adding code for "KB", but I'm not opposed to a kB/KiB config option for KLocale::formatByteSize. I'm just not sure how many users other than those reading this bug report (which is turning into a discussion forum btw) are going to care enough to change that option... 625519 60 bluedzins 2008-07-16 16:47:31 +0000 Of course I am not for overconfigurability, but to have configurable KiB/1024 KB/1000 such options are required ( ) KiB/1024 ( ) KB/1000 and just almost by granted, by changing this to [ ] KiB instead of KB [ ] 1024 instead of 1000 you get four not two possibilities. > I'm not opposed to a kB/KiB config option for KLocale::formatByteSize. Does it mean there will be one global function which get this as an input and calculate string, or each app on its own should calculate it using KLocale::formatByteSize? If the former -- I vote for it. Anyway, even with two choices I'll be happy. So maybe instead of further discussion "what is the point of KB/1024" let's focus on even minimal fix. 625567 61 meta 2008-07-16 18:38:17 +0000 > Is a crime that I would set it for KB/1024? I don't simply get it. > Let me use use my computer the way I used it for 22 years. So because your computer displayed wrong values for 22 years, you want it to continue to display wrong values. Don't you see how silly that seems to the rest of us? Are you like this with other bugs? Should we have checkboxes every time someone fixes a bug, in case people prefer to continue having incorrect data displayed? > it's also about making the world a slightly more sensible place by not > propagating ambiguities onto more people. Bravo! 625582 62 bluedzins 2008-07-16 19:13:20 +0000 > So because your computer displayed wrong values for 22 years, you want it to > continue to display wrong values. Don't you see how silly that seems to the > rest of us? Values were correct, and I would like to continue to use them as before, and I am happy to be in a good company here. I would appreciate if you stop forcing your opinion how _my_ computer should work as well overusing words like silly, bizarre, etc. Thank you. I think everything was said already so there is no point for further discussion on this subject. 625607 63 meta 2008-07-16 19:55:30 +0000 Values were not correct. k = 1024 and M = 1024*1024 was never correct; there are standards for this stuff, and it is not a matter of opinion, no matter how many people think otherwise. I don't care how your computer works. Patch it to call bytes "octets" if you like. I just care about KDE displaying *correct* information and abiding by open international standards. 625632 64 bluedzins 2008-07-16 20:26:10 +0000 I never used k for 1024, it was K. And the meaning of words is not of divine origin, people use it, people understand it, thus it makes correct usage and meaning. ZX81 had 1KB memory (1024), ZXSpectrum 48KB (48*1024) and so on. It made the meaning of K once for good. Oh boy, we should "correct" all the info sources, starting from wiki, because, shame-o-shame, it quotes ZX81 had... 1KB memory. > no matter how many people think otherwise. It matters. It is a language after all. Get some people, add some time and you will get "standard", voila. 625640 65 meta 2008-07-16 20:43:00 +0000 We're not talking about the meanings of words, we're talking about SI units. The SI units aren't defined by popular usage or by what random pages on Wikipedia say. And this isn't about K = 1024. That was never a problem. Back in the days of the ZX81, k was 1000 and K was 1024 and everyone was happy. The problem started in the late 80s when disk and memory sizes started to hit MB and GB ranges, and people glossed over the K/k distinction and decided to casually redefine giga- and mega- prefixes. I would actually support an option to keep K = 1024, as that's distinguishable from the SI kilo prefix k = 1000. But that doesn't help with GB and MB, so I doubt it'd make you happy. 625646 66 bluedzins 2008-07-16 21:07:53 +0000 Mathew, look at things that can agree, rather we disagree, ok? Again: [x] _iB instead of _B [ ] pow of 2 scale instead of pow of 10 (default values). This makes weekend user happy (KB/1000), this makes you happy (? KiB/1024), this makes me happy (KB/1024), this makes everybody happy. Why not make KDE the way everybody is happy? 625654 67 meta 2008-07-16 21:23:59 +0000 The problem is that there are four possible combinations of your proposed checkboxes, and two of them result in KDE displaying incorrect information. In fact, one is an option literally nobody has said they want. I don't think KDE should provide users with the option of displaying incorrect information, no matter how much any individual may want it. That way lies madness. I mean, some users don't like file permissions, so should there be an option to pretend all files are owned by the logged in user even when they aren't? I think formatting preferences are fine, but if you want incorrect information displayed, it's reasonable to tell you you should have to patch the source yourself. 625695 68 bluedzins 2008-07-16 22:35:08 +0000 > The problem is that there are four possible combinations of your proposed > checkboxes, and two of them result in KDE displaying incorrect information. > In fact, one is an option literally nobody has said they want. Ok, let's make it three options :-) > I mean, some users don't like file permissions, so should there be an option > to pretend all files are owned by the logged in user even when they aren't? Some users don't like to use access time info, and guess what, there is an option for it. > I think formatting preferences are fine, but if you want incorrect > information displayed, it's reasonable to tell you you should have to patch > the source yourself. Fair enough (the non-SI does not make it incorrect though). 693391 69 camspam 2009-01-03 22:24:55 +0000 OK unfortunaly konqueror in kde 3.5.10 still misslabels them, led to confusion when a website required a 10MB file and konqueror reported 9.7, but was over 10,000,000 bytes, it should at least be renamed in the old version. 705790 70 xeriouxi 2009-01-26 04:47:34 +0000 I personally can't stand the use of KiB, MiB, GiB, etc. and KDE is the only desktop environment I know that uses this prefix system. I think it should be an optional feature, if anything, and that KB, MB, GB, etc. should be used by default so as not to confuse people. The 'mainstream' computer users in this world have, IMO, has grown used to KB, MB, GB, etc. and I would expect that many people do/would not like this change. 785853 71 35014 alanalpert 2009-07-03 12:47:52 +0000 Created attachment 35014 Provides KB = 2^10 bytes behaviour This patch will not be applied to KDE, but if you need this behavior you can apply this patch to get it. Originally submitted by Michael Pyne to kde-devel list. 785854 72 35015 alanalpert 2009-07-03 12:50:13 +0000 Created attachment 35015 Provides kB = 10^3 bytes behaviour This patch is not expected to be applied to KDE. However if you need this behavior you may apply the patch yourself. 785858 73 alanalpert 2009-07-03 12:55:47 +0000 Attachments have been added that can provide all of these requested varying behaviors to Konqueror (4.4) if people need them. However, since Konqueror does display file size as wished for in the bug description this bug should be marked as resolved/implemented. 790403 74 majewsky 2009-07-11 14:40:18 +0000 (In reply to comment #70) > I think it should be > an optional feature, if anything, and that KB, MB, GB, etc. should be used by > default so as not to confuse people. Interestingly, there has not been any report about a user confused by KiB, MiB, GiB, etc. since Dolphinpart uses these units since KDE 4.0. Remember that SI is not optional (professionals are even forced to use it in every country of the world except for Liberia, Sri Lanka, and the USA *sigh*). 792523 75 mpyne 2009-07-15 04:23:58 +0000 Revision 996857 adds support for JEDEC units and metric units in addition to the IEC units already supported. (JEDEC is the standard for the "traditional" units used in KDE 3.5. I was as surprised to find out they actually were standardized as anyone else...). Add the BinaryUnitDialect=0 option to the [Locale] group of your $KDEHOME/share/config/kdeglobals file. setting to 0 (or leaving unset, of course) gives you the current default of IEC units since they are unambiguous and in accordance with the current revision of the relevant standards documents. Setting to 1 gives you JEDEC units. Setting to 2 gives you metric (yes, real powers-of-10, lowercase k instead of K, metric units). There was more added in that commit for developers but nothing that pertains to this bug. Everyone has what they want, unless what you want is to keep someone else from having what they want. There will be no GUI. I consider this feature request fixed. If you see uses of binary units in KDE not in accordance with what you've selected then the application involved probably manually handles the conversion instead of using formatByteUnits, in which case a bug should be opened against that application. 2123386 76 a.samirh78 2022-05-14 15:15:47 +0000 *** Bug 364321 has been marked as a duplicate of this bug. *** 12915 2005-10-08 02:46:05 +0000 2005-10-08 02:46:05 +0000 Implement SI and IEC standard byte prefixes prefix.diff text/plain 5607 kde ZGlmZiAtVSAzIC1kSHJOIG9yaWdpbmFsIGZpbGVzL2dsb2JhbC5jcHAgbmV3IGZpbGVzL2dsb2Jh bC5jcHAKLS0tIG9yaWdpbmFsIGZpbGVzL2dsb2JhbC5jcHAJMjAwNS0xMC0wNyAxNToyMDo0My4w MDAwMDAwMDAgLTA3MDAKKysrIG5ldyBmaWxlcy9nbG9iYWwuY3BwCTIwMDUtMTAtMDcgMTY6NTY6 NDMuMDAwMDAwMDAwIC0wNzAwCkBAIC00NSw0NyArNDUsMTA2IEBACiAjaW5jbHVkZSA8dm9sbWd0 Lmg+CiAjZW5kaWYKIAotS0lPX0VYUE9SVCBRU3RyaW5nIEtJTzo6Y29udmVydFNpemUoIEtJTzo6 ZmlsZXNpemVfdCBzaXplICkKK0tJT19FWFBPUlQgUVN0cmluZyBLSU86OmNvbnZlcnRTaXplVG9T SSggS0lPOjpmaWxlc2l6ZV90IHNpemUgKQogewotICAgIGRvdWJsZSBmc2l6ZSA9IHNpemU7Ci0g ICAgUVN0cmluZyBzOworCS8vIFBlciBJRUMgNjAwMjctMgorCisJLy8gU0ktU3RhbmRhcmQgcHJl Zml4ZXMKKwkvL1RlcmEtYnl0ZQkJVEIJCTEwXjEyCTEsMDAwLDAwMCwwMDAsMDAwIGJ5dGVzCisJ Ly9HaWdhLWJ5dGUJCUdCCQkxMF45CTEsMDAwLDAwMCwwMDAgYnl0ZXMKKwkvL01lZ2EtYnl0ZQkJ TUIJCTEwXjYJMSwwMDAsMDAwIGJ5dGVzCisJLy9LaWxvLWJ5dGUJCWtCCQkxMF4zCTEsMDAwIGJ5 dGVzCisKKwlkb3VibGUgZnNpemUgPSBzaXplOworCVFTdHJpbmcgczsKICAgICAvLyBHaWdhLWJ5 dGUKLSAgICBpZiAoIHNpemUgPj0gMTA3Mzc0MTgyNCApCi0gICAgewotICAgICAgICBmc2l6ZSAv PSAxMDczNzQxODI0LjA7Ci0gICAgICAgIGlmICggZnNpemUgPiAxMDI0ICkgLy8gVGVyYS1ieXRl Ci0gICAgICAgICAgICBzID0gaTE4biggIiUxIFRCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCkt PmZvcm1hdE51bWJlcihmc2l6ZSAvIDEwMjQuMCwgMSkpOwotICAgICAgICBlbHNlCi0gICAgICAg ICAgICBzID0gaTE4biggIiUxIEdCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51 bWJlcihmc2l6ZSwgMSkpOwotICAgIH0KKwlpZiAoIHNpemUgPj0gMTAwMDAwMDAwMCApCisJewor CQlmc2l6ZSAvPSAxMDAwMDAwMDAwLjA7CisJCWlmICggZnNpemUgPiAxMDAwICkgLy8gVGVyYS1i eXRlCisJCQlzID0gaTE4biggIiUxIFRCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1h dE51bWJlcihmc2l6ZSAvIDEwMDAuMCwgMSkpOworCQllbHNlCisJCQlzID0gaTE4biggIiUxIEdC IiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6ZSwgMSkpOworCX0K ICAgICAvLyBNZWdhLWJ5dGUKLSAgICBlbHNlIGlmICggc2l6ZSA+PSAxMDQ4NTc2ICkKLSAgICB7 Ci0gICAgICAgIGZzaXplIC89IDEwNDg1NzYuMDsKLSAgICAgICAgcyA9IGkxOG4oICIlMSBNQiIg KS5hcmcoIEtHbG9iYWw6OmxvY2FsZSgpLT5mb3JtYXROdW1iZXIoZnNpemUsIDEpKTsKLSAgICB9 CisJZWxzZSBpZiAoIHNpemUgPj0gMTAwMDAwMCApCisJeworCQlmc2l6ZSAvPSAxMDAwMDAwLjA7 CisJCXMgPSBpMThuKCAiJTEgTUIiICkuYXJnKCBLR2xvYmFsOjpsb2NhbGUoKS0+Zm9ybWF0TnVt YmVyKGZzaXplLCAxKSk7CisJfQogICAgIC8vIEtpbG8tYnl0ZQotICAgIGVsc2UgaWYgKCBzaXpl ID49IDEwMjQgKQotICAgIHsKLSAgICAgICAgZnNpemUgLz0gMTAyNC4wOwotICAgICAgICBzID0g aTE4biggIiUxIEtCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6 ZSwgMSkpOwotICAgIH0KKwllbHNlIGlmICggc2l6ZSA+PSAxMDAwICkKKwl7CisJCWZzaXplIC89 IDEwMDAuMDsKKwkJcyA9IGkxOG4oICIlMSBrQiIgKS5hcmcoIEtHbG9iYWw6OmxvY2FsZSgpLT5m b3JtYXROdW1iZXIoZnNpemUsIDEpKTsKKwl9CiAgICAgLy8gSnVzdCBieXRlCi0gICAgZWxzZSBp ZiAoIHNpemUgPiAwICkKLSAgICB7Ci0gICAgICAgIHMgPSBpMThuKCAiJTEgQiIgKS5hcmcoIEtH bG9iYWw6OmxvY2FsZSgpLT5mb3JtYXROdW1iZXIoZnNpemUsIDApKTsKLSAgICB9CisJZWxzZSBp ZiAoIHNpemUgPiAwICkKKwl7CisJCXMgPSBpMThuKCAiJTEgQiIgKS5hcmcoIEtHbG9iYWw6Omxv Y2FsZSgpLT5mb3JtYXROdW1iZXIoZnNpemUsIDApKTsKKwl9CiAgICAgLy8gTm90aGluZwotICAg IGVsc2UKLSAgICB7Ci0gICAgICAgIHMgPSBpMThuKCAiMCBCIiApOwotICAgIH0KLSAgICByZXR1 cm4gczsKKwllbHNlCisJeworCQlzID0gaTE4biggIjAgQiIgKTsKKwl9CisJcmV0dXJuIHM7CiB9 CiAKLUtJT19FWFBPUlQgUVN0cmluZyBLSU86OmNvbnZlcnRTaXplRnJvbUtCKCBLSU86OmZpbGVz aXplX3Qga2JTaXplICkKK0tJT19FWFBPUlQgUVN0cmluZyBLSU86OmNvbnZlcnRTaXplVG9CaW5h cnkoIEtJTzo6ZmlsZXNpemVfdCBzaXplICkKIHsKLSAgICByZXR1cm4gY29udmVydFNpemUoa2JT aXplICogMTAyNCk7CisJLy8gUGVyIElFQyA2MDAyNy0yCisKKwkvLyBCaW5hcnkgcHJlZml4ZXMK KwkvL1RlYmktYnl0ZQkJVGlCCQkyXjQwCTEsMDk5LDUxMSw2MjcsNzc2IGJ5dGVzCisJLy9HaWJp LWJ5dGUJCUdpQgkJMl4zMAkxLDA3Myw3NDEsODI0IGJ5dGVzCisJLy9NZWJpLWJ5dGUJCU1pQgkJ Ml4yMAkxLDA0OCw1NzYgYnl0ZXMKKwkvL0tpYmktYnl0ZQkJS2lCCQkyXjEwCTEsMDI0IGJ5dGVz CisKKwlkb3VibGUgZnNpemUgPSBzaXplOworCVFTdHJpbmcgczsKKyAgICAvLyBHaWJpLWJ5dGUK KwlpZiAoIHNpemUgPj0gMTA3Mzc0MTgyNCApCisJeworCQlmc2l6ZSAvPSAxMDczNzQxODI0LjA7 CisJCWlmICggZnNpemUgPiAxMDI0ICkgLy8gVGViaS1ieXRlCisJCQlzID0gaTE4biggIiUxIFRp QiIgKS5hcmcoIEtHbG9iYWw6OmxvY2FsZSgpLT5mb3JtYXROdW1iZXIoZnNpemUgLyAxMDI0LjAs IDEpKTsKKwkJZWxzZQorCQkJcyA9IGkxOG4oICIlMSBHaUIiICkuYXJnKCBLR2xvYmFsOjpsb2Nh bGUoKS0+Zm9ybWF0TnVtYmVyKGZzaXplLCAxKSk7CisJfQorICAgIC8vIE1lYmktYnl0ZQorCWVs c2UgaWYgKCBzaXplID49IDEwNDg1NzYgKQorCXsKKwkJZnNpemUgLz0gMTA0ODU3Ni4wOworCQlz ID0gaTE4biggIiUxIE1pQiIgKS5hcmcoIEtHbG9iYWw6OmxvY2FsZSgpLT5mb3JtYXROdW1iZXIo ZnNpemUsIDEpKTsKKwl9CisgICAgLy8gS2liaS1ieXRlCisJZWxzZSBpZiAoIHNpemUgPj0gMTAy NCApCisJeworCQlmc2l6ZSAvPSAxMDI0LjA7CisJCXMgPSBpMThuKCAiJTEgS2lCIiApLmFyZygg S0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6ZSwgMSkpOworCX0KKyAgICAvLyBK dXN0IGJ5dGUKKwllbHNlIGlmICggc2l6ZSA+IDAgKQorCXsKKwkJcyA9IGkxOG4oICIlMSBCIiAp LmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6ZSwgMCkpOworCX0KKyAg ICAvLyBOb3RoaW5nCisJZWxzZQorCXsKKwkJcyA9IGkxOG4oICIwIEIiICk7CisJfQorCXJldHVy biBzOworfQorCitLSU9fRVhQT1JUIFFTdHJpbmcgS0lPOjpjb252ZXJ0U2l6ZUZyb21rQiggS0lP OjpmaWxlc2l6ZV90IGtiU2l6ZSApCit7CisJcmV0dXJuIGNvbnZlcnRTaXplKGtiU2l6ZSAqIDEw MDApOworfQorCitLSU9fRVhQT1JUIFFTdHJpbmcgS0lPOjpjb252ZXJ0U2l6ZUZyb21LaUIoIEtJ Tzo6ZmlsZXNpemVfdCBrYlNpemUgKQoreworCXJldHVybiBjb252ZXJ0U2l6ZShrYlNpemUgKiAx MDI0KTsKIH0KIAogS0lPX0VYUE9SVCBRU3RyaW5nIEtJTzo6bnVtYmVyKCBLSU86OmZpbGVzaXpl X3Qgc2l6ZSApCmRpZmYgLVUgMyAtZEhyTiBvcmlnaW5hbCBmaWxlcy9nbG9iYWwuaCBuZXcgZmls ZXMvZ2xvYmFsLmgKLS0tIG9yaWdpbmFsIGZpbGVzL2dsb2JhbC5oCTIwMDUtMTAtMDcgMTY6MDE6 MjIuMDAwMDAwMDAwIC0wNzAwCisrKyBuZXcgZmlsZXMvZ2xvYmFsLmgJMjAwNS0xMC0wNyAxNjo1 NzoxMS4wMDAwMDAwMDAgLTA3MDAKQEAgLTQ0LDEyICs0NCwyMiBAQAogICB0eXBlZGVmIHF1bG9u Z2xvbmcgZmlsZXNpemVfdDsKIAogICAvKioKLSAgICogQ29udmVydHMgQHAgc2l6ZSBmcm9tIGJ5 dGVzIHRvIHRoZSBzdHJpbmcgcmVwcmVzZW50YXRpb24uCisgICAqIENvbnZlcnRzIEBwIHNpemUg ZnJvbSBieXRlcyB0byB0aGUgSUVDIDYwMDAyNy0yIFNJLXByZWZpeGVkCisgICAqIHN0cmluZyBy ZXByZXNlbnRhdGlvbi4KICAgICoKICAgICogQHBhcmFtICBzaXplICBzaXplIGluIGJ5dGVzCiAg ICAqIEByZXR1cm4gY29udmVydGVkIHNpemUgYXMgYSBzdHJpbmcgLSBlLmcuIDEyMy40IGtCICwg MTIuMCBNQgogICAgKi8KLSAgS0lPX0VYUE9SVCBRU3RyaW5nIGNvbnZlcnRTaXplKCBLSU86OmZp bGVzaXplX3Qgc2l6ZSApOworICBLSU9fRVhQT1JUIFFTdHJpbmcgY29udmVydFNpemVUb1NJKCBL SU86OmZpbGVzaXplX3Qgc2l6ZSApOworCisgIC8qKgorICAgKiBDb252ZXJ0cyBAcCBzaXplIGZy b20gYnl0ZXMgdG8gdGhlIElFQyA2MDAwMjctMiBCaW5hcnktcHJlZml4ZWQKKyAgICogc3RyaW5n IHJlcHJlc2VudGF0aW9uLgorICAgKgorICAgKiBAcGFyYW0gIHNpemUgIHNpemUgaW4gYnl0ZXMK KyAgICogQHJldHVybiBjb252ZXJ0ZWQgc2l6ZSBhcyBhIHN0cmluZyAtIGUuZy4gMTIzLjQgS2lC ICwgMTIuMCBNaUIKKyAgICovCisgIEtJT19FWFBPUlQgUVN0cmluZyBjb252ZXJ0U2l6ZVRvQmlu YXJ5KCBLSU86OmZpbGVzaXplX3Qgc2l6ZSApOwogCiAgIC8qKgogICAgKiBDb252ZXJ0cyBhIHNp emUgdG8gYSBzdHJpbmcgcmVwcmVzZW50YXRpb24KQEAgLTYxLDEyICs3MSwyMCBAQAogICBLSU9f RVhQT1JUIFFTdHJpbmcgbnVtYmVyKCBLSU86OmZpbGVzaXplX3Qgc2l6ZSApOwogCiAgIC8qKgot ICAgKiBDb252ZXJ0cyBzaXplIGZyb20ga2lsby1ieXRlcyB0byB0aGUgc3RyaW5nIHJlcHJlc2Vu dGF0aW9uLgorICAgKiBDb252ZXJ0cyBzaXplIGZyb20ga2lsby1ieXRlcyAoMTBeMykgdG8gdGhl IHN0cmluZyByZXByZXNlbnRhdGlvbi4KICAgICoKLSAgICogQHBhcmFtICBrYlNpemUgIHNpemUg aW4ga2lsby1ieXRlcworICAgKiBAcGFyYW0gIGtiU2l6ZSAgc2l6ZSBpbiBraWxvLWJ5dGVzICgx MF4zKQogICAgKiBAcmV0dXJuIGNvbnZlcnRlZCBzaXplIGFzIGEgc3RyaW5nIC0gZS5nLiAxMjMu NCBrQiAsIDEyLjAgTUIKICAgICovCi0gICBLSU9fRVhQT1JUIFFTdHJpbmcgY29udmVydFNpemVG cm9tS0IoIEtJTzo6ZmlsZXNpemVfdCBrYlNpemUgKTsKKyAgIEtJT19FWFBPUlQgUVN0cmluZyBj b252ZXJ0U2l6ZUZyb21rQiggS0lPOjpmaWxlc2l6ZV90IGtiU2l6ZSApOworCisgIC8qKgorICAg KiBDb252ZXJ0cyBzaXplIGZyb20ga2liaS1ieXRlcyAoMl4xMCkgdG8gdGhlIHN0cmluZyByZXBy ZXNlbnRhdGlvbi4KKyAgICoKKyAgICogQHBhcmFtICBrYlNpemUgIHNpemUgaW4ga2liaS1ieXRl cyAoMl4xMCkKKyAgICogQHJldHVybiBjb252ZXJ0ZWQgc2l6ZSBhcyBhIHN0cmluZyAtIGUuZy4g MTIzLjQgS2lCICwgMTIuMCBNaUIKKyAgICovCisgICBLSU9fRVhQT1JUIFFTdHJpbmcgY29udmVy dFNpemVGcm9tS2lCKCBLSU86OmZpbGVzaXplX3Qga2JTaXplICk7CiAKICAgLyoqCiAgICAqIENh bGN1bGF0ZXMgcmVtYWluaW5nIHRpbWUgaW4gc2Vjb25kcyBmcm9tIHRvdGFsIHNpemUsIHByb2Nl c3NlZCBzaXplIGFuZCBzcGVlZC4K 12919 2005-10-08 23:22:53 +0000 2005-10-08 23:22:53 +0000 Updated IEC Prefix Patch prefix.diff text/plain 5520 kde ZGlmZiAtVSAzIC1kSHJOIG9yaWdpbmFsIGZpbGVzL2dsb2JhbC5jcHAgbmV3IGZpbGVzL2dsb2Jh bC5jcHAKLS0tIG9yaWdpbmFsIGZpbGVzL2dsb2JhbC5jcHAJMjAwNS0xMC0wNyAxNToyMDo0My4w MDAwMDAwMDAgLTA3MDAKKysrIG5ldyBmaWxlcy9nbG9iYWwuY3BwCTIwMDUtMTAtMDggMTM6MjM6 NDkuMDAwMDAwMDAwIC0wNzAwCkBAIC00NSwzMCArNDUsODYgQEAKICNpbmNsdWRlIDx2b2xtZ3Qu aD4KICNlbmRpZgogCi1LSU9fRVhQT1JUIFFTdHJpbmcgS0lPOjpjb252ZXJ0U2l6ZSggS0lPOjpm aWxlc2l6ZV90IHNpemUgKQorS0lPX0VYUE9SVCBRU3RyaW5nIEtJTzo6Y29udmVydFNpemVUb1NJ KCBLSU86OmZpbGVzaXplX3Qgc2l6ZSApCiB7CisgICAgLyoKKyAgICBTSS1TdGFuZGFyZCBwcmVm aXhlcyBwZXIgSUVDIDYwMDI3LTIKKworICAgIFRlcmEtYnl0ZQkJVEIJCTEwXjEyCTEsMDAwLDAw MCwwMDAsMDAwIGJ5dGVzCisgICAgR2lnYS1ieXRlCQlHQgkJMTBeOQkxLDAwMCwwMDAsMDAwIGJ5 dGVzCisgICAgTWVnYS1ieXRlCQlNQgkJMTBeNgkxLDAwMCwwMDAgYnl0ZXMKKyAgICBLaWxvLWJ5 dGUJCWtCCQkxMF4zCTEsMDAwIGJ5dGVzCisgICAgKi8KKwogICAgIGRvdWJsZSBmc2l6ZSA9IHNp emU7CiAgICAgUVN0cmluZyBzOwogICAgIC8vIEdpZ2EtYnl0ZQotICAgIGlmICggc2l6ZSA+PSAx MDczNzQxODI0ICkKKyAgICBpZiAoIHNpemUgPj0gMTAwMDAwMDAwMCApCiAgICAgewotICAgICAg ICBmc2l6ZSAvPSAxMDczNzQxODI0LjA7Ci0gICAgICAgIGlmICggZnNpemUgPiAxMDI0ICkgLy8g VGVyYS1ieXRlCi0gICAgICAgICAgICBzID0gaTE4biggIiUxIFRCIiApLmFyZyggS0dsb2JhbDo6 bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6ZSAvIDEwMjQuMCwgMSkpOworICAgICAgICBmc2l6 ZSAvPSAxMDAwMDAwMDAwLjA7CisgICAgICAgIGlmICggZnNpemUgPiAxMDAwICkgLy8gVGVyYS1i eXRlCisgICAgICAgICAgICBzID0gaTE4biggIiUxIFRCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxl KCktPmZvcm1hdE51bWJlcihmc2l6ZSAvIDEwMDAuMCwgMSkpOwogICAgICAgICBlbHNlCiAgICAg ICAgICAgICBzID0gaTE4biggIiUxIEdCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1h dE51bWJlcihmc2l6ZSwgMSkpOwogICAgIH0KICAgICAvLyBNZWdhLWJ5dGUKLSAgICBlbHNlIGlm ICggc2l6ZSA+PSAxMDQ4NTc2ICkKKyAgICBlbHNlIGlmICggc2l6ZSA+PSAxMDAwMDAwICkKICAg ICB7Ci0gICAgICAgIGZzaXplIC89IDEwNDg1NzYuMDsKKyAgICAgICAgZnNpemUgLz0gMTAwMDAw MC4wOwogICAgICAgICBzID0gaTE4biggIiUxIE1CIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCkt PmZvcm1hdE51bWJlcihmc2l6ZSwgMSkpOwogICAgIH0KICAgICAvLyBLaWxvLWJ5dGUKKyAgICBl bHNlIGlmICggc2l6ZSA+PSAxMDAwICkKKyAgICB7CisgICAgICAgIGZzaXplIC89IDEwMDAuMDsK KyAgICAgICAgcyA9IGkxOG4oICIlMSBrQiIgKS5hcmcoIEtHbG9iYWw6OmxvY2FsZSgpLT5mb3Jt YXROdW1iZXIoZnNpemUsIDEpKTsKKyAgICB9CisgICAgLy8gSnVzdCBieXRlCisgICAgZWxzZSBp ZiAoIHNpemUgPiAwICkKKyAgICB7CisgICAgICAgIHMgPSBpMThuKCAiJTEgQiIgKS5hcmcoIEtH bG9iYWw6OmxvY2FsZSgpLT5mb3JtYXROdW1iZXIoZnNpemUsIDApKTsKKyAgICB9CisgICAgLy8g Tm90aGluZworICAgIGVsc2UKKyAgICB7CisgICAgICAgIHMgPSBpMThuKCAiMCBCIiApOworICAg IH0KKyAgICByZXR1cm4gczsKK30KKworS0lPX0VYUE9SVCBRU3RyaW5nIEtJTzo6Y29udmVydFNp emVUb0JpbmFyeSggS0lPOjpmaWxlc2l6ZV90IHNpemUgKQoreworICAgIC8qCisgICAgQmluYXJ5 IHByZWZpeGVzIHBlciBJRUMgNjAwMjctMgorCisgICAgVGViaS1ieXRlCQlUaUIJCTJeNDAJMSww OTksNTExLDYyNyw3NzYgYnl0ZXMKKyAgICBHaWJpLWJ5dGUJCUdpQgkJMl4zMAkxLDA3Myw3NDEs ODI0IGJ5dGVzCisgICAgTWViaS1ieXRlCQlNaUIJCTJeMjAJMSwwNDgsNTc2IGJ5dGVzCisgICAg S2liaS1ieXRlCQlLaUIJCTJeMTAJMSwwMjQgYnl0ZXMKKyAgICAqLworCisgICAgZG91YmxlIGZz aXplID0gc2l6ZTsKKyAgICBRU3RyaW5nIHM7CisgICAgLy8gR2liaS1ieXRlCisgICAgaWYgKCBz aXplID49IDEwNzM3NDE4MjQgKQorICAgIHsKKyAgICAgICAgZnNpemUgLz0gMTA3Mzc0MTgyNC4w OworICAgICAgICBpZiAoIGZzaXplID4gMTAyNCApIC8vIFRlYmktYnl0ZQorICAgICAgICAgICAg cyA9IGkxOG4oICIlMSBUaUIiICkuYXJnKCBLR2xvYmFsOjpsb2NhbGUoKS0+Zm9ybWF0TnVtYmVy KGZzaXplIC8gMTAyNC4wLCAxKSk7CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHMgPSBpMThu KCAiJTEgR2lCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6ZSwg MSkpOworICAgIH0KKyAgICAvLyBNZWJpLWJ5dGUKKyAgICBlbHNlIGlmICggc2l6ZSA+PSAxMDQ4 NTc2ICkKKyAgICB7CisgICAgICAgIGZzaXplIC89IDEwNDg1NzYuMDsKKyAgICAgICAgcyA9IGkx OG4oICIlMSBNaUIiICkuYXJnKCBLR2xvYmFsOjpsb2NhbGUoKS0+Zm9ybWF0TnVtYmVyKGZzaXpl LCAxKSk7CisgICAgfQorICAgIC8vIEtpYmktYnl0ZQogICAgIGVsc2UgaWYgKCBzaXplID49IDEw MjQgKQogICAgIHsKICAgICAgICAgZnNpemUgLz0gMTAyNC4wOwotICAgICAgICBzID0gaTE4bigg IiUxIEtCIiApLmFyZyggS0dsb2JhbDo6bG9jYWxlKCktPmZvcm1hdE51bWJlcihmc2l6ZSwgMSkp OworICAgICAgICBzID0gaTE4biggIiUxIEtpQiIgKS5hcmcoIEtHbG9iYWw6OmxvY2FsZSgpLT5m b3JtYXROdW1iZXIoZnNpemUsIDEpKTsKICAgICB9CiAgICAgLy8gSnVzdCBieXRlCiAgICAgZWxz ZSBpZiAoIHNpemUgPiAwICkKQEAgLTgzLDcgKzEzOSwxOCBAQAogICAgIHJldHVybiBzOwogfQog Ci1LSU9fRVhQT1JUIFFTdHJpbmcgS0lPOjpjb252ZXJ0U2l6ZUZyb21LQiggS0lPOjpmaWxlc2l6 ZV90IGtiU2l6ZSApCitLSU9fRVhQT1JUIFFTdHJpbmcgS0lPOjpjb252ZXJ0U2l6ZSggS0lPOjpm aWxlc2l6ZV90IGtiU2l6ZSApCit7CisgICAgLy8gVXNlIElFQyBiaW5hcnkgcHJlZml4ZXMgYnkg ZGVmYXVsdC4uLgorICAgIHJldHVybiBjb252ZXJ0U2l6ZVRvQmluYXJ5KGtiU2l6ZSk7Cit9CisK K0tJT19FWFBPUlQgUVN0cmluZyBLSU86OmNvbnZlcnRTaXplRnJvbWtCKCBLSU86OmZpbGVzaXpl X3Qga2JTaXplICkKK3sKKyAgICByZXR1cm4gY29udmVydFNpemUoa2JTaXplICogMTAwMCk7Cit9 CisKK0tJT19FWFBPUlQgUVN0cmluZyBLSU86OmNvbnZlcnRTaXplRnJvbUtpQiggS0lPOjpmaWxl c2l6ZV90IGtiU2l6ZSApCiB7CiAgICAgcmV0dXJuIGNvbnZlcnRTaXplKGtiU2l6ZSAqIDEwMjQp OwogfQpkaWZmIC1VIDMgLWRIck4gb3JpZ2luYWwgZmlsZXMvZ2xvYmFsLmggbmV3IGZpbGVzL2ds b2JhbC5oCi0tLSBvcmlnaW5hbCBmaWxlcy9nbG9iYWwuaAkyMDA1LTEwLTA3IDE2OjAxOjIyLjAw MDAwMDAwMCAtMDcwMAorKysgbmV3IGZpbGVzL2dsb2JhbC5oCTIwMDUtMTAtMDcgMTg6NTI6MTUu MDAwMDAwMDAwIC0wNzAwCkBAIC00NCwxMSArNDQsMzAgQEAKICAgdHlwZWRlZiBxdWxvbmdsb25n IGZpbGVzaXplX3Q7CiAKICAgLyoqCi0gICAqIENvbnZlcnRzIEBwIHNpemUgZnJvbSBieXRlcyB0 byB0aGUgc3RyaW5nIHJlcHJlc2VudGF0aW9uLgorICAgKiBDb252ZXJ0cyBAcCBzaXplIGZyb20g Ynl0ZXMgdG8gdGhlIElFQyA2MDAwMjctMiBTSS1wcmVmaXhlZAorICAgKiBzdHJpbmcgcmVwcmVz ZW50YXRpb24uCiAgICAqCiAgICAqIEBwYXJhbSAgc2l6ZSAgc2l6ZSBpbiBieXRlcwogICAgKiBA cmV0dXJuIGNvbnZlcnRlZCBzaXplIGFzIGEgc3RyaW5nIC0gZS5nLiAxMjMuNCBrQiAsIDEyLjAg TUIKICAgICovCisgIEtJT19FWFBPUlQgUVN0cmluZyBjb252ZXJ0U2l6ZVRvU0koIEtJTzo6Zmls ZXNpemVfdCBzaXplICk7CisKKyAgLyoqCisgICAqIENvbnZlcnRzIEBwIHNpemUgZnJvbSBieXRl cyB0byB0aGUgSUVDIDYwMDAyNy0yIEJpbmFyeS1wcmVmaXhlZAorICAgKiBzdHJpbmcgcmVwcmVz ZW50YXRpb24uCisgICAqCisgICAqIEBwYXJhbSAgc2l6ZSAgc2l6ZSBpbiBieXRlcworICAgKiBA cmV0dXJuIGNvbnZlcnRlZCBzaXplIGFzIGEgc3RyaW5nIC0gZS5nLiAxMjMuNCBLaUIgLCAxMi4w IE1pQgorICAgKi8KKyAgS0lPX0VYUE9SVCBRU3RyaW5nIGNvbnZlcnRTaXplVG9CaW5hcnkoIEtJ Tzo6ZmlsZXNpemVfdCBzaXplICk7CisKKyAgLyoqCisgICAqIENvbnZlcnRzIEBwIHNpemUgZnJv bSBieXRlcyB0byB0aGUgSUVDIDYwMDAyNy0yIEJpbmFyeS1wcmVmaXhlZAorICAgKiBzdHJpbmcg cmVwcmVzZW50YXRpb24uIFdyYXBzIGNvbnZlcnRTaXplVG9CaW5hcnkoKQorICAgKgorICAgKiBA cGFyYW0gIHNpemUgIHNpemUgaW4gYnl0ZXMKKyAgICogQHJldHVybiBjb252ZXJ0ZWQgc2l6ZSBh cyBhIHN0cmluZyAtIGUuZy4gMTIzLjQgS2lCICwgMTIuMCBNaUIKKyAgICovCiAgIEtJT19FWFBP UlQgUVN0cmluZyBjb252ZXJ0U2l6ZSggS0lPOjpmaWxlc2l6ZV90IHNpemUgKTsKIAogICAvKioK QEAgLTYxLDEyICs4MCwyMCBAQAogICBLSU9fRVhQT1JUIFFTdHJpbmcgbnVtYmVyKCBLSU86OmZp bGVzaXplX3Qgc2l6ZSApOwogCiAgIC8qKgotICAgKiBDb252ZXJ0cyBzaXplIGZyb20ga2lsby1i eXRlcyB0byB0aGUgc3RyaW5nIHJlcHJlc2VudGF0aW9uLgorICAgKiBDb252ZXJ0cyBzaXplIGZy b20ga2lsby1ieXRlcyAoMTBeMykgdG8gdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbi4KICAgICoK LSAgICogQHBhcmFtICBrYlNpemUgIHNpemUgaW4ga2lsby1ieXRlcworICAgKiBAcGFyYW0gIGti U2l6ZSAgc2l6ZSBpbiBraWxvLWJ5dGVzICgxMF4zKQogICAgKiBAcmV0dXJuIGNvbnZlcnRlZCBz aXplIGFzIGEgc3RyaW5nIC0gZS5nLiAxMjMuNCBrQiAsIDEyLjAgTUIKICAgICovCi0gICBLSU9f RVhQT1JUIFFTdHJpbmcgY29udmVydFNpemVGcm9tS0IoIEtJTzo6ZmlsZXNpemVfdCBrYlNpemUg KTsKKyAgIEtJT19FWFBPUlQgUVN0cmluZyBjb252ZXJ0U2l6ZUZyb21rQiggS0lPOjpmaWxlc2l6 ZV90IGtiU2l6ZSApOworCisgIC8qKgorICAgKiBDb252ZXJ0cyBzaXplIGZyb20ga2liaS1ieXRl cyAoMl4xMCkgdG8gdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbi4KKyAgICoKKyAgICogQHBhcmFt ICBrYlNpemUgIHNpemUgaW4ga2liaS1ieXRlcyAoMl4xMCkKKyAgICogQHJldHVybiBjb252ZXJ0 ZWQgc2l6ZSBhcyBhIHN0cmluZyAtIGUuZy4gMTIzLjQgS2lCICwgMTIuMCBNaUIKKyAgICovCisg ICBLSU9fRVhQT1JUIFFTdHJpbmcgY29udmVydFNpemVGcm9tS2lCKCBLSU86OmZpbGVzaXplX3Qg a2JTaXplICk7CiAKICAgLyoqCiAgICAqIENhbGN1bGF0ZXMgcmVtYWluaW5nIHRpbWUgaW4gc2Vj b25kcyBmcm9tIHRvdGFsIHNpemUsIHByb2Nlc3NlZCBzaXplIGFuZCBzcGVlZC4K 35014 2009-07-03 12:47:52 +0000 2009-07-03 12:47:52 +0000 Provides KB = 2^10 bytes behaviour kb_binary.patch text/plain 2419 alanalpert SW5kZXg6IGtkZWNvcmUvbG9jYWxpemF0aW9uL2tsb2NhbGUuY3BwCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGtk ZWNvcmUvbG9jYWxpemF0aW9uL2tsb2NhbGUuY3BwCShyZXZpc2lvbiA5ODg5MDMpCisrKyBrZGVj b3JlL2xvY2FsaXphdGlvbi9rbG9jYWxlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMjI4LDYgKzIy OCw3IEBACiAgIGludCB3b3JraW5nV2Vla0VuZERheTsKICAgaW50IHdlZWtEYXlPZlByYXk7CiAg IEtMb2NhbGU6OkRpZ2l0U2V0IGRhdGVUaW1lRGlnaXRTZXQ7CisgIGJvb2wgaGlzdG9yaWNhbEJp bmFyeVVuaXRzOyAvLyBTZWUgSUVDIDYwMDI3LTIgaS5lLiBraWJpYnl0ZSwgbWViaWJ5dGUsIGV0 Yy4KIAogICAvLyBGSVhNRTogVGVtcG9yYXJ5IHVudGlsIGZ1bGwgbGFuZ3VhZ2Utc2Vuc2l0aXZp dHkgaW1wbGVtZW50ZWQuCiAgIGJvb2wgbGFuZ3VhZ2VTZW5zaXRpdmVEaWdpdHM7CkBAIC00NDMs NiArNDQ0LDggQEAKICAgcmVhZENvbmZpZ0VudHJ5KCJQb3NpdGl2ZVNpZ24iLCAiIiwgcG9zaXRp dmVTaWduKTsKICAgcmVhZENvbmZpZ0VudHJ5KCJOZWdhdGl2ZVNpZ24iLCAiLSIsIG5lZ2F0aXZl U2lnbik7CiAKKyAgcmVhZENvbmZpZ0VudHJ5KCJIaXN0b3JpY2FsQmluYXJ5VW5pdHMiLCBmYWxz ZSwgaGlzdG9yaWNhbEJpbmFyeVVuaXRzKTsKKwogICByZWFkQ29uZmlnTnVtRW50cnkoIkRpZ2l0 U2V0IiwgS0xvY2FsZTo6QXJhYmljRGlnaXRzLAogICAgICAgICAgICAgICAgICAgICAgZGlnaXRT ZXQsIEtMb2NhbGU6OkRpZ2l0U2V0KTsKICAgLy8gRklYTUU6IFRlbXBvcmFyeSB1bnRpbCBmdWxs IGxhbmd1YWdlLXNlbnNpdGl2aXR5IGltcGxlbWVudGVkLgpAQCAtMTM1NCwyNyArMTM1Nyw0MyBA QAogICAgIC8vTWViaS1ieXRlICAgICAgICAgICAgIE1pQiAgICAgICAgICAgICAyXjIwICAgIDEs MDQ4LDU3NiBieXRlcwogICAgIC8vS2liaS1ieXRlICAgICAgICAgICAgIEtpQiAgICAgICAgICAg ICAyXjEwICAgIDEsMDI0IGJ5dGVzCiAKKyAgICBLTG9jYWxpemVkU3RyaW5nIFRpQihraTE4bigi JTEgVGlCIikpOworICAgIEtMb2NhbGl6ZWRTdHJpbmcgR2lCKGtpMThuKCIlMSBHaUIiKSk7Cisg ICAgS0xvY2FsaXplZFN0cmluZyBNaUIoa2kxOG4oIiUxIE1pQiIpKTsKKyAgICBLTG9jYWxpemVk U3RyaW5nIEtpQihraTE4bigiJTEgS2lCIikpOworCisgICAgLy8gSWYgdXNpbmcgaGlzdG9yaWMg cHJlZml4ZXMsIGNvbnZlcnQgdW5pdHMuCisgICAgLy8gSWYgd2Ugd2VyZSB0byBiZSBkb2luZyB0 aGlzIG9mdGVuLCBpdCBtYXkgcGF5IHRvIGNhY2hlIHRoZSB1c2VyCisgICAgLy8gcHJlZmVyZW5j ZQorICAgIGlmIChkLT5oaXN0b3JpY2FsQmluYXJ5VW5pdHMpIHsKKyAgICAgICAgVGlCID0ga2kx OG4oIiUxIFRCIik7CisgICAgICAgIEdpQiA9IGtpMThuKCIlMSBHQiIpOworICAgICAgICBNaUIg PSBraTE4bigiJTEgTUIiKTsKKyAgICAgICAgS2lCID0ga2kxOG4oIiUxIEtCIik7CisgICAgfQor CiAgICAgUVN0cmluZyBzOworCiAgICAgLy8gR2liaS1ieXRlCiAgICAgaWYgKCBzaXplID49IDEw NzM3NDE4MjQuMCApCiAgICAgewogICAgICAgICBzaXplIC89IDEwNzM3NDE4MjQuMDsKICAgICAg ICAgaWYgKCBzaXplID4gMTAyNCApIC8vIFRlYmktYnl0ZQotICAgICAgICAgICAgcyA9IGkxOG4o ICIlMSBUaUIiLCBmb3JtYXROdW1iZXIoc2l6ZSAvIDEwMjQuMCwgMSkpOworICAgICAgICAgICAg cyA9IFRpQi5zdWJzKCBmb3JtYXROdW1iZXIoc2l6ZSAvIDEwMjQuMCwgMSkgKS50b1N0cmluZygp OwogICAgICAgICBlbHNlCi0gICAgICAgICAgICBzID0gaTE4biggIiUxIEdpQiIsIGZvcm1hdE51 bWJlcihzaXplLCAxKSk7CisgICAgICAgICAgICBzID0gR2lCLnN1YnMoIGZvcm1hdE51bWJlcihz aXplLCAxKSApLnRvU3RyaW5nKCk7CiAgICAgfQogICAgIC8vIE1lYmktYnl0ZQogICAgIGVsc2Ug aWYgKCBzaXplID49IDEwNDg1NzYuMCApCiAgICAgewogICAgICAgICBzaXplIC89IDEwNDg1NzYu MDsKLSAgICAgICAgcyA9IGkxOG4oICIlMSBNaUIiLCBmb3JtYXROdW1iZXIoc2l6ZSwgMSkpOwor ICAgICAgICBzID0gTWlCLnN1YnMoIGZvcm1hdE51bWJlcihzaXplLCAxKSApLnRvU3RyaW5nKCk7 CiAgICAgfQogICAgIC8vIEtpYmktYnl0ZQogICAgIGVsc2UgaWYgKCBzaXplID49IDEwMjQuMCAp CiAgICAgewogICAgICAgICBzaXplIC89IDEwMjQuMDsKLSAgICAgICAgcyA9IGkxOG4oICIlMSBL aUIiLCBmb3JtYXROdW1iZXIoc2l6ZSwgMSkpOworICAgICAgICBzID0gS2lCLnN1YnMoIGZvcm1h dE51bWJlcihzaXplLCAxKSApLnRvU3RyaW5nKCk7CiAgICAgfQogICAgIC8vIEp1c3QgYnl0ZQog ICAgIGVsc2UgaWYgKCBzaXplID4gMCApCg== 35015 2009-07-03 12:50:13 +0000 2009-07-03 12:50:13 +0000 Provides kB = 10^3 bytes behaviour siUnits.patch text/plain 4292 alanalpert SW5kZXg6IGtkZWNvcmUvbG9jYWxpemF0aW9uL2tsb2NhbGUuY3BwCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGtk ZWNvcmUvbG9jYWxpemF0aW9uL2tsb2NhbGUuY3BwCShyZXZpc2lvbiA5ODg0MTEpCisrKyBrZGVj b3JlL2xvY2FsaXphdGlvbi9rbG9jYWxlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMjI5LDYgKzIy OSw5IEBACiAgIGludCB3ZWVrRGF5T2ZQcmF5OwogICBLTG9jYWxlOjpEaWdpdFNldCBkYXRlVGlt ZURpZ2l0U2V0OwogCisgIC8vIERpZ2l0YWwgU2l6ZSBVbml0cworICBib29sIHNpQnl0ZXM7IC8v IHRvIHVzZSBrQiwgTUIuLi4sIGluc3RlYWQgb2YgS2lCLCBNaUIuLi4KKwogICAvLyBGSVhNRTog VGVtcG9yYXJ5IHVudGlsIGZ1bGwgbGFuZ3VhZ2Utc2Vuc2l0aXZpdHkgaW1wbGVtZW50ZWQuCiAg IGJvb2wgbGFuZ3VhZ2VTZW5zaXRpdmVEaWdpdHM7CiAKQEAgLTQ0Myw2ICs0NDYsOCBAQAogICBy ZWFkQ29uZmlnRW50cnkoIlBvc2l0aXZlU2lnbiIsICIiLCBwb3NpdGl2ZVNpZ24pOwogICByZWFk Q29uZmlnRW50cnkoIk5lZ2F0aXZlU2lnbiIsICItIiwgbmVnYXRpdmVTaWduKTsKIAorICByZWFk Q29uZmlnRW50cnkoIlNJQnl0ZXMiLCBmYWxzZSwgc2lCeXRlcyk7CisKICAgcmVhZENvbmZpZ051 bUVudHJ5KCJEaWdpdFNldCIsIEtMb2NhbGU6OkFyYWJpY0RpZ2l0cywKICAgICAgICAgICAgICAg ICAgICAgIGRpZ2l0U2V0LCBLTG9jYWxlOjpEaWdpdFNldCk7CiAgIC8vIEZJWE1FOiBUZW1wb3Jh cnkgdW50aWwgZnVsbCBsYW5ndWFnZS1zZW5zaXRpdml0eSBpbXBsZW1lbnRlZC4KQEAgLTEzNDAs NTIgKzEzNDUsNzUgQEAKICAgcmV0dXJuIG1hbnRTdHJpbmcgKyBleHBTdHJpbmc7CiB9CiAKLS8v IElmIHNvbWVvbmUgd2FudHMgdGhlIFNJLXN0YW5kYXJkIHByZWZpeGVzIGtCL01CL0dCL1RCLCBJ IHdvdWxkIHJlY29tbWVuZAotLy8gYSBoaWRkZW4ga2NvbmZpZyBvcHRpb24gYW5kIGdldHRpbmcg dGhlIGNvZGUgZnJvbSAjNTcyNDAgaW50byB0aGUgc2FtZQotLy8gbWV0aG9kLCBzbyB0aGF0IGFs bCBLREUgYXBwcyB1c2UgdGhlIHNhbWUgdW5pdCwgaW5zdGVhZCBvZiBsZXR0aW5nIGVhY2ggYXBw IGRlY2lkZS4KLQogUVN0cmluZyBLTG9jYWxlOjpmb3JtYXRCeXRlU2l6ZSggZG91YmxlIHNpemUg KSBjb25zdAogewotICAgIC8vIFBlciBJRUMgNjAwMjctMgogCi0gICAgLy8gQmluYXJ5IHByZWZp eGVzCisgICAgLy8gQmluYXJ5IHByZWZpeGVzIFBlciBJRUMgNjAwMjctMgogICAgIC8vVGViaS1i eXRlICAgICAgICAgICAgIFRpQiAgICAgICAgICAgICAyXjQwICAgIDEsMDk5LDUxMSw2MjcsNzc2 IGJ5dGVzCiAgICAgLy9HaWJpLWJ5dGUgICAgICAgICAgICAgR2lCICAgICAgICAgICAgIDJeMzAg ICAgMSwwNzMsNzQxLDgyNCBieXRlcwogICAgIC8vTWViaS1ieXRlICAgICAgICAgICAgIE1pQiAg ICAgICAgICAgICAyXjIwICAgIDEsMDQ4LDU3NiBieXRlcwogICAgIC8vS2liaS1ieXRlICAgICAg ICAgICAgIEtpQiAgICAgICAgICAgICAyXjEwICAgIDEsMDI0IGJ5dGVzCiAKKyAgICAvLyBTSSBw cmVmaXhlcworICAgIC8vIFRlcmFieXRlICAgICAgICAgICAgIFRCICAgICAgICAgICAgICAxMF4x MiAgIDEsMDAwLDAwMCwwMDAsMDAwIGJ5dGVzCisgICAgLy8gR2lnYWJ5dGUgICAgICAgICAgICAg R0IgICAgICAgICAgICAgIDEwXjkgICAgMSwwMDAsMDAwLDAwMCBieXRlcworICAgIC8vIE1lZ2Fi eXRlICAgICAgICAgICAgIE1CICAgICAgICAgICAgICAxMF42ICAgIDEsMDAwLDAwMCBieXRlcwor ICAgIC8vIEtpbG9ieXRlICAgICAgICAgICAgIGtCICAgICAgICAgICAgICAxMF4zICAgIDEsMDAw IGJ5dGVzCisKKyAgICAvLyBOb3RlIHRoYXQgU0kgdnMuIElFQyBpcyBjb3ZlcmVkIGluIGJ1ZyAj NTcyNDAKICAgICBRU3RyaW5nIHM7Ci0gICAgLy8gR2liaS1ieXRlCi0gICAgaWYgKCBzaXplID49 IDEwNzM3NDE4MjQuMCApCi0gICAgewotICAgICAgICBzaXplIC89IDEwNzM3NDE4MjQuMDsKLSAg ICAgICAgaWYgKCBzaXplID4gMTAyNCApIC8vIFRlYmktYnl0ZQotICAgICAgICAgICAgcyA9IGkx OG4oICIlMSBUaUIiLCBmb3JtYXROdW1iZXIoc2l6ZSAvIDEwMjQuMCwgMSkpOworCisgICAgaWYg KGQtPnNpQnl0ZXMpIHsvL1NJIHVuaXQgcHJlZml4ZXMKKyAgICAgICAgZG91YmxlIFQgPSAxMDAw MDAwMDAwMDAwLjA7CisgICAgICAgIGRvdWJsZSBHID0gMTAwMDAwMDAwMC4wOworICAgICAgICBk b3VibGUgTSA9IDEwMDAwMDAuMDsKKyAgICAgICAgZG91YmxlIGsgPSAxMDAwLjA7CisgICAgICAg IGlmICggc2l6ZSA+PSBUICkgeworICAgICAgICAgICAgcyA9IGkxOG4oICIlMSBUQiIsIGZvcm1h dE51bWJlcihzaXplL1QsIDEpKTsKKyAgICAgICAgfSBlbHNlIGlmIChzaXplID49IEcgKSB7Cisg ICAgICAgICAgICBzID0gaTE4biggIiUxIEdCIiwgZm9ybWF0TnVtYmVyKHNpemUvRywgMSkpOwor ICAgICAgICB9IGVsc2UgaWYgKHNpemUgPj0gTSApIHsKKyAgICAgICAgICAgIHMgPSBpMThuKCAi JTEgTUIiLCBmb3JtYXROdW1iZXIoc2l6ZS9NLCAxKSk7CisgICAgICAgIH0gZWxzZSBpZiAoc2l6 ZSA+PSBrICkgeworICAgICAgICAgICAgcyA9IGkxOG4oICIlMSBrQiIsIGZvcm1hdE51bWJlcihz aXplL2ssIDEpKTsKKyAgICAgICAgfSBlbHNlIGlmIChzaXplID4gMCl7IC8vQgorICAgICAgICAg ICAgcyA9IGkxOG4oICIlMSBCIiwgZm9ybWF0TnVtYmVyKHNpemUsIDApKTsKKyAgICAgICAgfSBl bHNlIHsKKyAgICAgICAgICAgIHMgPSBpMThuKCAiMCBCIiApOworICAgICAgICB9CisgICAgfWVs c2V7Ly9JRUMgNjAwMjctMiBwcmVmaXhlcworICAgICAgICAvLyBHaWJpLWJ5dGUKKyAgICAgICAg aWYgKCBzaXplID49IDEwNzM3NDE4MjQuMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHNpemUg Lz0gMTA3Mzc0MTgyNC4wOworICAgICAgICAgICAgaWYgKCBzaXplID4gMTAyNCApIC8vIFRlYmkt Ynl0ZQorICAgICAgICAgICAgICAgIHMgPSBpMThuKCAiJTEgVGlCIiwgZm9ybWF0TnVtYmVyKHNp emUgLyAxMDI0LjAsIDEpKTsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgICAgICBzID0g aTE4biggIiUxIEdpQiIsIGZvcm1hdE51bWJlcihzaXplLCAxKSk7CisgICAgICAgIH0KKyAgICAg ICAgLy8gTWViaS1ieXRlCisgICAgICAgIGVsc2UgaWYgKCBzaXplID49IDEwNDg1NzYuMCApCisg ICAgICAgIHsKKyAgICAgICAgICAgIHNpemUgLz0gMTA0ODU3Ni4wOworICAgICAgICAgICAgcyA9 IGkxOG4oICIlMSBNaUIiLCBmb3JtYXROdW1iZXIoc2l6ZSwgMSkpOworICAgICAgICB9CisgICAg ICAgIC8vIEtpYmktYnl0ZQorICAgICAgICBlbHNlIGlmICggc2l6ZSA+PSAxMDI0LjAgKQorICAg ICAgICB7CisgICAgICAgICAgICBzaXplIC89IDEwMjQuMDsKKyAgICAgICAgICAgIHMgPSBpMThu KCAiJTEgS2lCIiwgZm9ybWF0TnVtYmVyKHNpemUsIDEpKTsKKyAgICAgICAgfQorICAgICAgICAv LyBKdXN0IGJ5dGUKKyAgICAgICAgZWxzZSBpZiAoIHNpemUgPiAwICkKKyAgICAgICAgeworICAg ICAgICAgICAgcyA9IGkxOG4oICIlMSBCIiwgZm9ybWF0TnVtYmVyKHNpemUsIDApKTsKKyAgICAg ICAgfQorICAgICAgICAvLyBOb3RoaW5nCiAgICAgICAgIGVsc2UKLSAgICAgICAgICAgIHMgPSBp MThuKCAiJTEgR2lCIiwgZm9ybWF0TnVtYmVyKHNpemUsIDEpKTsKKyAgICAgICAgeworICAgICAg ICAgICAgcyA9IGkxOG4oICIwIEIiICk7CisgICAgICAgIH0KICAgICB9Ci0gICAgLy8gTWViaS1i eXRlCi0gICAgZWxzZSBpZiAoIHNpemUgPj0gMTA0ODU3Ni4wICkKLSAgICB7Ci0gICAgICAgIHNp emUgLz0gMTA0ODU3Ni4wOwotICAgICAgICBzID0gaTE4biggIiUxIE1pQiIsIGZvcm1hdE51bWJl cihzaXplLCAxKSk7Ci0gICAgfQotICAgIC8vIEtpYmktYnl0ZQotICAgIGVsc2UgaWYgKCBzaXpl ID49IDEwMjQuMCApCi0gICAgewotICAgICAgICBzaXplIC89IDEwMjQuMDsKLSAgICAgICAgcyA9 IGkxOG4oICIlMSBLaUIiLCBmb3JtYXROdW1iZXIoc2l6ZSwgMSkpOwotICAgIH0KLSAgICAvLyBK dXN0IGJ5dGUKLSAgICBlbHNlIGlmICggc2l6ZSA+IDAgKQotICAgIHsKLSAgICAgICAgcyA9IGkx OG4oICIlMSBCIiwgZm9ybWF0TnVtYmVyKHNpemUsIDApKTsKLSAgICB9Ci0gICAgLy8gTm90aGlu ZwotICAgIGVsc2UKLSAgICB7Ci0gICAgICAgIHMgPSBpMThuKCAiMCBCIiApOwotICAgIH0KICAg ICByZXR1cm4gczsKIH0KIAo=