Re: Suggestion on "int len" sanity

[Al Viro <viro@parcelfarce.linux.theplanet.co.uk>]

On Fri, Jun 03, 2005 at 11:45:51AM +0200, Geert Uytterhoeven wrote:
> On Thu, 2 Jun 2005, [iso-8859-1] J?rn Engel wrote:
> > 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...

Ugh, indeed - who the hell had come up with _that_?

> > 
> > 	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.

BS from the beginning to end - we are talking about symlink bodies.
These are *not* going to be 2Gb long.

And that quite neatly shows why the whole plan is a non-starter - you need
to understand what's going on in the code being mangled.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/