Re: [PATCH,RFC] ext3: Add support for non-native signed/unsigned htree hash algorithms

From: Olaf Weber
Date: Mon Nov 03 2008 - 02:42:58 EST

Next message: Ingo Molnar: "Re: [PATCH] Identify which executable object the userspace addressbelongs to. Store thread group leader id, and use it to lookup theaddress in the process's map. We could have looked up the addresson thread's map, but the thread might not exist by the time we arecalled. The process might not exist either, but if you are readingtrace_pipe, that is unlikely."
Previous message: Larry Finger: "System hang from holding left shift key"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Theodore Tso writes:
> On Wed, Oct 22, 2008 at 05:22:21PM -0700, Andrew Morton wrote:

>> > + if (((int) c) == -1) {
>>
>> arm says
>>
>> fs/ext3/super.c: In function `ext3_fill_super':
>> fs/ext3/super.c:1750: warning: comparison is always false due to limited range of data type
>>
>> Also, is there any way in which this new code can be, umm, cleaned up?

> Hmm..... is it considered safe to depend on the userspace limits.h
> header file? I guess if we trust that header file to be correct we
> could check the value of CHAR_MIN and/or CHAR_MAX as defined by
> limits.h.

> Alternatively we could do an #ifdef __CHAR_UNSIGNED__, which is
> defined by gcc. The manual for gcc tells us not to depend on it, but
> to depend on limits.h instead.

> Any thoughts, or comments? Does anyone know if the Intel compiler
> will DTRT with either of these approaches?

Why not write the test like this?

if ((char)-1 > 0) {
/* char is unsigned */
} else {
/* char is signed */
}

--
Olaf Weber
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/