Tsantilas Christos wrote:
Henrik Nordstrom wrote:
On tis, 2007-07-31 at 21:09 +0000, chtsanti wrote:
Please avoid casting unless needed. The compiler automatically promotes
to larger types when needed, and will tell you if you try to do the
reverse..
So stop casting things to (int64_t).
OK. Sometimes I am using this typecasts just to note that here this
operations must be done in 64bits. But yes this is why the comments
exists ...
Moreover casting maybe it is dangerous in the cases where the signess of
an integer changes....
The exception is the upshifts if the value shifted may be large. But I
think these should be changed to store bytes to begin with avoiding the
problem. It's really more of a theoretical configuration limitation than
a real limitation. It's very unlikely anyone would want to configure
readahead_gap or quick_abort_min/max as large as 2 GB or more..
So make
Config.readAheadGap and Config.quickAbort.min/max b_size_t instead of
kb_size_t, and stop upshifting it to compare... Maybe even should be a
b_int64_t.
Probably we should even kill the kb_size_t type entirely, converting
them all to b_int64_t.
I did not change it now because, if I am not wrong, the kb_size_t type
has the meaning that the users enters the configuration parameter in
Kbytes (eg "quick_abort_min 128" is 128Kbytes).
But if it is a required I will do it ....
Regards,
Christos
How about I first dig-up/rewrite some old code I wrote years ago that
parses a value nX where n is some integer and X is one of the
B/KB/MB/GB/...etc base strings?
Then we can go about making all these annoying magic squid.conf values
more human readable where they are supposed to be bandwidth amounts or
storage sizes. And have the parser determine the minimum values base
multiplier.
Interest?
Amos
