On tis, 2007-08-07 at 09:48 +0300, Tsantilas Christos wrote:
> At the end I just put quick_abort_min and quick_abort_max to its
> original behavior. They are storing values in kilobytes and if the units
> are missing kilobytes are the default.
Ok.
> But a problem I am seeing is that at the beggin
Tsantilas Christos wrote:
At the end I just put quick_abort_min and quick_abort_max to its
original behavior. They are storing values in kilobytes and if the units
are missing kilobytes are the default.
It is very easy to change it and also is easy to make parser to not
require spaces between val
At the end I just put quick_abort_min and quick_abort_max to its
original behavior. They are storing values in kilobytes and if the units
are missing kilobytes are the default.
It is very easy to change it and also is easy to make parser to not
require spaces between value and units.
But a problem
On fre, 2007-08-03 at 00:35 +1200, Amos Jeffries wrote:
> Although having said that, the current parser requires whitespace
> between the value and the units. I'm not certain that is a good thing.
Been like that for ever. Or at least as long as Squid has been parsing
units.. i.e. Squid-1.1 or so
Amos Jeffries wrote:
Alex Rousskov wrote:
On Wed, 2007-08-01 at 20:18 +1200, Amos Jeffries wrote:
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?
That would be nice. I think S
Henrik Nordstrom wrote:
On ons, 2007-08-01 at 16:53 -0600, Alex Rousskov wrote:
If there is consensus that units should be required everywhere, I am
fine with that (but still worried).
I wote for requiring units in all unit based directives. Seeing them
without unit just calls for confusion b
Alex Rousskov wrote:
On Wed, 2007-08-01 at 20:18 +1200, Amos Jeffries wrote:
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?
That would be nice. I think Squid3 already has some
On ons, 2007-08-01 at 16:53 -0600, Alex Rousskov wrote:
> If there is consensus that units should be required everywhere, I am
> fine with that (but still worried).
I wote for requiring units in all unit based directives. Seeing them
without unit just calls for confusion both by the admin and Squ
Hi,
Alex Rousskov wrote:
>
> If a unitless configuration is rejected, there is no problem. If it is
> accepted (with a warning) and then interpreted differently from Squid2,
> I think there is a problem because many admins will [continue to] ignore
> the warning.
The configuration line "quick_ab
On Thu, 2007-08-02 at 00:40 +0200, Henrik Nordstrom wrote:
> On tor, 2007-08-02 at 01:32 +0300, Tsantilas Christos wrote:
>
> > At the end I convert Config.readAheadGap and Config.quickAbort.min/max
> > to b_int64_t types.
>
> Ok.
>
> > But this is changes the default units for Config.quickAbort
On tor, 2007-08-02 at 01:32 +0300, Tsantilas Christos wrote:
> At the end I convert Config.readAheadGap and Config.quickAbort.min/max
> to b_int64_t types.
Ok.
> But this is changes the default units for Config.quickAbort.min/max
> parameters and make them different than those of squid26 configu
Hi all,
Henrik Nordstrom wrote:
> 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_int
On Wed, 2007-08-01 at 20:18 +1200, Amos Jeffries wrote:
> 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?
That would be nice. I think Squid3 already has something similar for
On ons, 2007-08-01 at 10:35 +0300, Tsantilas Christos wrote:
> 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 inte
Tsantilas Christos wrote:
Henrik Nordstrom wrote:
On tis, 2007-07-31 at 21:09 +, 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.
Henrik Nordstrom wrote:
> On tis, 2007-07-31 at 21:09 +, 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 u
On tis, 2007-07-31 at 21:09 +, chtsanti wrote:
> - Some convertions of variables to 64bit integers, for which I am not
> sure if really needed but they used to hold results of 64bit
> operations and I think it is not safe to downgrade 64bit integers ...
Please avoid casting unless needed. The
17 matches
Mail list logo
