Re: Suggestion on "int len" sanity

[Geert Uytterhoeven]

On Thu, 2 Jun 2005, [iso-8859-1] Jörn Engel wrote:
> On Thu, 2 June 2005 09:28:55 +0200, XIAO Gang wrote:
> > 3. The similar situation occurs in fs/namei.c, vfs_readlink(). Here it does 
> > not matter if len
> > is declared to be unsigned, but for size_t, we have to take care about the 
> > size of size_t.
> 
> You could possibly change the code to:
> 
> int vfs_readlink(struct dentry *dentry, char __user *buffer, int buflen, const char *link)
> {
> 	union {
> 		unsigned len;
                ^^^^^^^^
Plain unsigned is deprecated.

> 		int ret;
> 	} u;

Ugh...

> 
> 	u.ret = PTR_ERR(link);
> 	if (IS_ERR(link))
> 		goto out;
> 
> 	u.len = strlen(link);
> 	if (u.len > (unsigned) buflen)
> 		u.len = buflen;
> 	if (copy_to_user(buffer, link, u.len))
> 		u.ret = -EFAULT;
> out:
> 	return u.ret;
> }

buflen should be size_t.

Since the return value may be negative, it should be signed. But int is not an
option, since size_t is 64 bit on 64-bit machines, while int is still 32-bit.
So the return type should be ssize_t.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds