[PATCH] ubi: int versus size_t printk warnings

[PATCH] ubi: int versus size_t printk warnings

[Alan]

Another mtd driver, another set of 32bit assumptions. Please compile mtd
stuff on 64bit now and then, or if stuff is for 32bit only systems then
add the right CONFIG rules.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.20-rc6-mm3/drivers/mtd/ubi/io.c linux-2.6.20-rc6-mm3/drivers/mtd/ubi/io.c
--- linux.vanilla-2.6.20-rc6-mm3/drivers/mtd/ubi/io.c	2007-01-31 14:20:41.000000000 +0000
+++ linux-2.6.20-rc6-mm3/drivers/mtd/ubi/io.c	2007-01-31 15:24:50.142281168 +0000
@@ -129,8 +129,8 @@
 			yield();
 			goto retry;
 		}
-		ubi_err("error %d while reading %d bytes from PEB %d:%d, "
-			"read %d bytes", err, len, pnum, offset, *read);
+		ubi_err("error %d while reading %Zd bytes from PEB %d:%d, "
+			"read %Zd bytes", err, len, pnum, offset, *read);
 		dump_stack();
 	}
 
@@ -190,14 +190,14 @@
 
 	err = mtd_write(io, buf, pnum, offset, len, written);
 	if (unlikely(err)) {
-		ubi_err("error %d while writing %d bytes to PEB %d:%d, written"
-			" %d bytes", err, len, pnum, offset, *written);
+		ubi_err("error %d while writing %Zd bytes to PEB %d:%d, written"
+			" %Zd bytes", err, len, pnum, offset, *written);
 		dump_stack();
 	}
 
 	/* The below is just for debugging and is compiled out if disabled */
 	if (ubi_dbg_is_write_failure() && !err) {
-		ubi_err("cannot write %d bytes to PEB %d:%d (emulated)",
+		ubi_err("cannot write %Zd bytes to PEB %d:%d (emulated)",
 			len, pnum, offset);
 		dump_stack();
 		return -EIO;
@@ -597,7 +597,7 @@
 
 		/* The shift must be aligned to 32-bit boundary */
 		if (io->vid_hdr_shift % 4) {
-			ubi_err("unaligned VID header shift %d",
+			ubi_err("unaligned VID header shift %Zd",
 				io->vid_hdr_shift);
 			goto out_mtd;
 		}
@@ -615,7 +615,7 @@
 	    io->leb_start < io->vid_hdr_offset + UBI_VID_HDR_SIZE ||
 	    io->leb_start > io->peb_size - UBI_VID_HDR_SIZE ||
 	    io->leb_start % io->min_io_size) {
-		ubi_err("bad VID header (%d) or data offsets (%d)",
+		ubi_err("bad VID header (%Zd) or data offsets (%Zd)",
 			io->vid_hdr_offset, io->leb_start);
 		goto out_mtd;
 	}
@@ -847,12 +847,12 @@
 		goto bad;
 	}
 	if (unlikely(vid_hdr_offset != io->vid_hdr_offset)) {
-		ubi_err("bad VID header offset %d at PEB %d, expected %d",
+		ubi_err("bad VID header offset %d at PEB %d, expected %Zd",
 			vid_hdr_offset, pnum, io->vid_hdr_offset);
 		goto bad;
 	}
 	if (unlikely(leb_start != io->leb_start)) {
-		ubi_err("bad data offset %d at PEB %d, expected %d",
+		ubi_err("bad data offset %d at PEB %d, expected %Zd",
 			pnum, leb_start, io->leb_start);
 		goto bad;
 	}

Re: [PATCH] ubi: int versus size_t printk warnings

[David Woodhouse]

On Wed, 2007-01-31 at 17:02 +0000, Alan wrote:
> Another mtd driver, another set of 32bit assumptions. Please compile mtd
> stuff on 64bit now and then, or if stuff is for 32bit only systems then
> add the right CONFIG rules.

We've been building MTD stuff on 64-bit machines since about 1999, when
I first put a DiskOnChip in an ISA eval board in an Alpha. 

The _problematic_ 32-bit assumption in MTD code is the fact that device
size is limited to 4GiB. That used to be "insanely large" in the context
of flash chips, but it's not so any more. We'll have to deal with that
soon enough.

> +               ubi_err("error %d while reading %Zd bytes from PEB %d:%d, "

Nak. %Zd is a gratuitous GNUism. In C, we use %zd.

Artem (dedekind) is the correct person to deal with UBI stuff. I've
added him to Cc.

-- 
dwmw2

Re: [PATCH] ubi: int versus size_t printk warnings

[Artem Bityutskiy]

On Wed, 2007-01-31 at 17:06 +0000, David Woodhouse wrote:
> > +               ubi_err("error %d while reading %Zd bytes from PEB %d:%d, "
> 
> Nak. %Zd is a gratuitous GNUism. In C, we use %zd.
> 
> Artem (dedekind) is the correct person to deal with UBI stuff. I've
> added him to Cc.

Yeah, there was a problem of mixing size_t and int in UBI and it was
mostly fixed - thanks to akpm. These are leftovers. I will look through
the code and fix things like this.

Thanks.

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