Henrik Nordstrom wrote:
[moved to squid-dev without cc to original poster]
On tis, 2008-11-18 at 23:25 +1300, Amos Jeffries wrote:
Henrik Nordstrom wrote:
On tis, 2008-11-18 at 21:14 +1300, Amos Jeffries wrote:
Do you have the same 64/32 bit settings and --with-large-files on both
builds?
Didn't we make the cache and swap.state format large-files independent
in Squid-3?
Not 3.0 that I know of.
Checking..
StoreObject TLV data:
uint64_t swap_file_sz;
StoreSwapLogData:
uint64_t swap_file_sz;
No off_t references anywhere, so the on-disk format should be
large-files agnostic from what I can tell.
But it's very sensitive to 32/64-bit as pretty much everything then
changes, for example time_t changes..
Certainly not different between stable9 and stable10.
Agreed.
The only piece of s10 that touched the filesystem would have possibly
reduced files being saved with negative lengths. Not added unreadable
files anywhere.
?
Reading 3.0.STABLE10 diff... and not much wiser what this is about.
But this fragment won't work:
StoreIOBuffer(size_t aLength, int64_t anOffset, char *someData) :
+ if (aLength <0) {
size_t aLength is an unsigned quantity and can never be <0.
wonder why gcc doesn't warn on this.. maybe I have forgot that warning
flag again.. oh, right I don't have that warning option enabled for
Squid yet.. (part of -Wextra which is till a bit too noisy on our code,
no separate flag exists from what I can tell)
Regards
Henrik
Ah, looks like I was confused between the ssize_t and size_t types.
They are not equivalent.
Question then to the more informed, is it better to make StoreIOBuffer
accept a ssize_t or revert the patch?
The reason for having it in the first place was that only one of a few
places in the code were doing a subtraction of two values then checking
for negatives. The rest were doing a subtraction and assuming that it
was always >= 0.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10
Current Beta Squid 3.1.0.2
