On Fri, Sep 5, 2014 at 3:54 PM, David Vasek <va...@fido.cz> wrote:
> On Fri, 5 Sep 2014, Philip Guenther wrote:
>
>> While di_blocks is unsigned, daddr_t is signed so we cast and print blocks
>> as long long's.
>
> Noted, thanks.
>
>> quad_t id_filesize; /* for DATA nodes, the size of the directory
>> */
>
>
> Is there any similar rule/limitation for the file size? Variable
> id_filesize, which is signed, gets data from di_size, which is unsigned. But
> considering the fact that both are 64-bit I agree that it won't present a
> real problem today and in quite a few years.
Hmm, should probably follow the same for file sizes, given that off_t
is signed. I guess that does on the list once this first diff is
in...
>> --- pass5.c 8 Jul 2014 17:19:24 -0000 1.45
>> +++ pass5.c 5 Sep 2014 08:36:43 -0000
>> @@ -336,8 +336,8 @@ pass5(void)
>> continue;
>> if (cg_inosused(cg)[i] & (1 << k))
>> continue;
>> - pwarn("ALLOCATED INODE %ld MARKED
>> FREE\n",
>> - c * fs->fs_ipg + i * 8 + k);
>> + pwarn("ALLOCATED INODE %lld MARKED
>> FREE\n",
>> + ((long long)c * fs->fs_ipg + i
>> * 8) + k);
>
>
> This is just for my understanding - the added parentheses around
> (long long)c * fs->fs_ipg + i * 8
> are there for compiler optimization, for better readability or for other
> reason? Thanks.
I want to make it clear that all the summing will be done in long
long. I suppose there's still the possibility of overflow in the i*8
multiplication, but the initial cast is enough to force all the
additions to be done in long longs.
(And yes, the parens I added are redundant for that; the C parsing
rules means that the types must propagate to all the additions
regardless of actual execution *order* of them...but I had to verify
the associativity in the spec to be sure, which means I should use
parens to make it clear to everyone...)
Philip Guenther
