[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-tiny
Subject:    Re: [PATCH] Fix compile problems with no-xattr.patch
From:       Matt Mackall <mpm () selenic ! com>
Date:       2007-10-05 0:41:47
Message-ID: 20071005004147.GI19691 () waste ! org
[Download RAW message or body]

On Thu, Oct 04, 2007 at 12:11:03PM -0700, Tim Bird wrote:
> Here is a fix for no-xattr.patch, for when CONFIG_XATTR=n.
> This resolves some build errors (I think linker errors, but
> it may have been compile problems).  It also adds
> a bunch more dependencies to fs/Kconfig.
> 
> Please replace no-xattr.patch with this one.
> -- Tim
> 

> 	depends on EXT2_FS
> +	depends on XATTR

You can use && here, I suspect it's preferred.

> bool "CIFS extended attributes"
> depends on CIFS
> +	depends on XATTR

Insidious tab.


> +#ifdef CONFIG_XATTR
> ssize_t generic_getxattr(struct dentry *dentry, const char *name, void *buffer, \
> size_t size); ssize_t generic_listxattr(struct dentry *dentry, char *buffer, size_t \
> buffer_size); int generic_setxattr(struct dentry *dentry, const char *name, const \
> void *value, size_t size, int flags); int generic_removexattr(struct dentry \
> *dentry, const char *name); +#else
> +#define generic_getxattr NULL
> +#define generic_listxattr NULL
> +#define generic_setxattr NULL
> +#define generic_removexattr NULL
> +#endif

That looks suspicious. NULL = ((void *)0), so things that were
expecting ssize_ts or ints are going to get upset. How about just 0 or
(0)?

-- 
Mathematics is the supreme nostalgia of our time.


[prev in list] [next in list] [prev in thread] [next in thread]