All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: dedekind@infradead.org
Cc: linux-mtd@lists.infradead.org
Subject: Re: [RFC / PATCH] ubiformat: make it work on mtd parts > 2GiB
Date: Tue, 10 Feb 2009 11:49:19 +0100	[thread overview]
Message-ID: <49915BAF.2070709@linutronix.de> (raw)
In-Reply-To: <1234261659.17790.117.camel@localhost.localdomain>

Artem Bityutskiy wrote:
> 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.

Yup, thanks for info. That makes sense.

> Anyway, the thing is that 31-bit should be more than enough for
> eraseblock number.
For now :)

> 
>> 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?
You are using -W which deprecated and -Wextra is doing the same thing. One 
of the things -Wextra does is adding -Wsign-compare so you have to add 
-Wno-sign-compare to stop that.

Sebastian
-- 
Firmensitz: 88690 Uhldingen, Auf dem Berg 3
Registergericht: Amtsgericht Freiburg i. Br., HRB 700 806;
StNr. 87007/07777; Ust-Id Nr.: DE252739476
Geschäftsführer: Heinz Egger, Thomas Gleixner

  reply	other threads:[~2009-02-10 10:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10  9:56 [RFC / PATCH] ubiformat: make it work on mtd parts > 2GiB Sebastian Andrzej Siewior
2009-02-10 10:06 ` Artem Bityutskiy
2009-02-10 10:17   ` Sebastian Andrzej Siewior
2009-02-10 10:27     ` Artem Bityutskiy
2009-02-10 10:49       ` Sebastian Andrzej Siewior [this message]
2009-02-11  7:30         ` Artem Bityutskiy
2009-02-11  9:05           ` [PATCH] get rid of "compare between signed and unsigned" warnings Sebastian Andrzej Siewior
2009-02-10 10:33   ` [PATCH v2] ubiformat: make it work on mtd parts > 2GiB Sebastian Andrzej Siewior
2009-02-11  7:30     ` Artem Bityutskiy
2009-02-11  8:56       ` Sebastian Andrzej Siewior
2009-02-11  9:04       ` [PATCH v3] " Sebastian Andrzej Siewior
2009-02-11 10:23         ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49915BAF.2070709@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.