seems I'm not the only one in favour of unsigned arithmetics where

------ Forwarded message ------
    From: Linus Torvalds <[EMAIL PROTECTED]>
 Subject: Re: Optimizations on long long multiply/divide on PowerPC32  don't work
    Date: Mon, 10 Dec 2001 10:52:07 -0800 (PST)
      To: Franz Sirl <[EMAIL PROTECTED]>
      Cc: Richard Henderson <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

On Mon, 10 Dec 2001, Franz Sirl wrote:
> >
> > Which part of FAT-FS actually tries to do a signed division?
> It's this code fragment:
>         inode->i_blocks = ((inode->i_size + inode->i_blksize - 1)
>                            & ~(inode->i_blksize - 1)) / 512;
> that is in inode.c/fat_read_root() and fat_fill_inode(). It's inode->i_size
> that is of type loff_t here.

Hmm, ok.

I've never really liked the signedness of "loff_t" (or "off_t"), as
negative numbers are illegal anyway, and are really only used for "seek
offset" case.

It might be a good idea to make the in-kernel sizes all be unsigned, to
avoid things like this being problematic.

For fat, the inode size is actually limited to 32 bits, so the above is
definitely _always_ a unsigned number, and a relatively small one at that.
So unsigned vs signed doesn't matter, but on the whole I'd prefer to
default to unsigned which tends to be faster anyway, and has less
surprising behaviour in case of bugs..

> It calculates the number of blocks here, so the rounding up might be wanted...

Yes, it does the rounding up by hand, but it does _not_ need or want the
"negative division" rounding part.

> Hehe, yeah, exactly :-). Anyway, Richard's patch works fine and gcc3 now is
> able to optimize the divdi3 call away.

Good. The code looks correct, even if I have this feeling that the kernel
might want changing too..



Gimp-developer mailing list

Reply via email to