Not too long ago, I committed a change in r51576[1] that, besides resolving a bug reported on ask.wireshark.org, also properly documented the max filesize autostop values to match the code. Previously, they were documented in SI units: kilobyte(s), megabyte(s), gigabyte(s); however, that did not match the code, so I changed the SI prefixes to IEC prefixes: kibibyte(s), mebibyte(s), gibibyte(s), and changed all MB -> MiB, etc.
This raised a question from one user (Tony Fortunato) on 2 LinkedIn groups (Wireshark[2] and Wireshark Users[3]), who thought these new prefixes were typos. Although these prefixes have been standardized since 1998, I suspect others will think they're typos as well simply because they're still not all that common. That said, I'm still in favor of using these prefixes if they indeed better describe the units used in the code; however, I'm now thinking that it would be better to change the code to use SI units and then change the prefixes back. For example, if a user wants to set a maximum file size, then I think it's more intuitive to the user to specify and expect SI, powers of 10, units to apply rather than the IEC, powers of 2, units. This might end up being a bit strange on some OS's (Windows, for example) to see a 977KB file size for file that's actually 1MB in size, but apparently at least one OS, Mac OS X version 10.6 will now use MB for all file and disk sizes so that same 1MB file will actually be correctly reported as such. This to me makes the most sense, and so I'm in favor of changing the code to (and prefixes back to) SI units. This could also be said of the capture buffer size, which is currently incorrectly reported as MB (when it's really MiB). What do others think before I make any changes to SI units? - Chris [1]: http://anonsvn.wireshark.org/viewvc?view=revision&revision=51576 [2]: http://www.linkedin.com/groups/anyone-else-notice-coooool- typo-2094006.S.5806548790450102272 [3]: www.linkedin.com/groups/anyone-else-notice-coooool- typo-64481.S.5806967531272949763 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
