Re: squid3-largeobj squid3/src HttpHdrRange.cc...

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
Received on Wed Aug 01 2007 - 02:18:29 MDT