Ok, I'm convinced. Who's going to convince IEEE?
Let's close the bug and make it clear that we don't have to start this
discussion again next month.
Eelco
Christopher Turner wrote:
As far as I have been able to test (Windows, Solaris) all operating
systems seem to use 1K == 1024 bytes when dealing with disk sizes,
files sizes and so on. Therefore, if we are using this information in
relation to buffers or file size checking then we MUST keep 1K == 1024
bytes. Reasons being:
- We don't want buffer overruns by a small number of bytes. This is
inefficient.
- If we are using the conversions to check size of uploaded files then
a file that is 10K on a user's system can be between 9217 and 10240
bytes. If our max upload size was 100K and we were using the 1K ==
1000 bytes conversion then any files between 10001 and 10240 bytes we
seem the correct size to the user (as reported by their OS) but would
fail on the size validation - not good.
I'm therefore very strongly -1 against this change. 1K should always
equal 1024 bytes (unless processor architecture changes to use base-10
logic). If people want alternative conversions for their particular
application then they should not be using the Wicket utility classes IMHO.
Regards,
Chris
>
>
> the only thing is we are using them for making max buffers
> So if we use it to make a buffer that should hold a 134KB file
> then:
>
> XXXsetBuffer(Bytes.kilobytes(134));
>
> should be able to hold that file exactly...
>
> Now the question is.. Is a file which is 134KB (windows reports that)
> 134000 bytes or not?
>
>
> johan
>
> Juergen Donnerstag wrote:
>
> >This was a request from Gili.
> >
> >"We should use 1 kilobyte = 1000 bytes as mention here:
> >http://encyclopedia.laborlawtalk.com/kilobyte
> >
> >This standard has been around since at least 1998 and I personally
> >believe most people think in terms of this standard anyway (i.e.
> >decimal, not binary system)."
> >
> >Based on the answers I have seen so far, we agree on this change. It
> >that correct? What are your votes?
> >
> >Juergen
> >
> >
> >-------------------------------------------------------
> >SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> >from IBM. Find simple to follow Roadmaps, straightforward articles,
> >informative Webcasts and more! Get everything you need to get up to
> >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id
<http://ads.osdn.com/?ad_idt77&alloc_id>492&op=click
> >_______________________________________________
> >Wicket-develop mailing list [email protected]
> >https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> >
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies from IBM. Find simple to follow Roadmaps,
> straightforward articles, informative Webcasts and more! Get
> everything you need to get up to speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492>> &op=click
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
