Re: [RFC / PATCH] ubiformat: make it work on mtd parts > 2GiB

[Artem Bityutskiy <dedekind@infradead.org>]

On Tue, 2009-02-10 at 11:17 +0100, Sebastian Andrzej Siewior wrote:
> > I do not think you need to make eraseblock number and offset to be
> > unsigned. In fact, I'd like them to be signed, because this is the same
> > we have in the kernel (in UBI/UBIFS), and I'd like to be more or less
> > consistent.
> That is a point. However those things should never be negative so maybe we 
> could change this in kernel.

They should not indeed be negative. However, signed numbers are just
much more appropriate when you write the code, because you may put an
error code there if something goes wrong.

For example, the UBIFS Garbage collector returns the freed eraseblock
number in case of success or a negative error code in case of failure.
Compare:

int ubifs_garbage_collect(struct ubifs_info *c)

and

int ubifs_garbage_collect(struct ubifs_info *c, unsigned int *leb)

The first prototype is what we have now. The second is what we would
have to have to be able to return LEB number and error code.

And vs. changing UBI/UBIFS - that would be really a lot of work.

Anyway, the thing is that 31-bit should be more than enough for
eraseblock number.

> While we here, I get a couple of "compare between signed and unsigned" 
> warnings from gcc. I tried to clean them up but I end up with huge patches 
> similar to this one. Are you aware of those or you simply don't get them?

I'd rather shut the warnings up by an gcc option - is there such an
option?

I mean, IMO most of these warnings are not really sane, and cleaning
that up just adds mess - you stop understanding why is something signed
or unsigned :-)

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)