On Sunday 10 March 2002 10:39 am, Florin Iucha wrote: > When compiling linux/fs/jfs/namei.c file the following warnings > occured: > > namei.c: In function `jfs_mkdir': > namei.c:200: warning: comparison is always false due to limited > range of data type > namei.c: In function `jfs_link': > namei.c:832: warning: comparison is always false due to limited > range of data type > namei.c: In function `jfs_rename': > namei.c:1175: warning: comparison is always false due to limited > range of data type
Sparc defines __kernel_nlink_t to be a short. All of the other architectures defind __kernel_nlink_t to be either an unsigned short, or something larger. JFS_LINK_MAX is defined to be 65535, which is not valid for a signed short. I don't think sparc needs __kernel_nlink_t to be signed, since none of the architecture-independent code would expect it to be, so it would make sense to change the sparc headers (asm-sparc/posix_types.h) to make it unsigned. The other altenative would be to limit JFS_LINK_MAX to 32767. I don't like imposing artificial limits. > Should I be worried about that? When could that cause problems? It shouldn't be a problem unless you have a directory with more than 32767 subdirectories or a file that is linked more than 32767 times. So, unless you are running test cases that are specifically stressing the n_link limits, you shouldn't have a problem because of this. _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
