linux-kernel - Re: [PATCH] adfs: add hexadecimal filetype suffix option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D8A7D7B.1080001@gmail.com>
Date:	Wed, 23 Mar 2011 23:08:43 +0000
From:	Stuart Swales <stuart.swales.croftnuisk@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] adfs: add hexadecimal filetype suffix option

The file typing code is using -1 (truncated to __u16) to represent the 
case when no explicit 12-bit file type was set on the file, such as is 
the case where the file has explicit 32-bit load and execute addresses 
(Acorn specific legacy stuff, started with the BBC Micro).  It would 
seem to be best if the -1 were replaced by 0xffffu.

Stuart

On 23/03/2011 20:58, Andrew Morton wrote:
> On Wed, 23 Mar 2011 21:36:48 +0100
> Geert Uytterhoeven<geert@...ux-m68k.org>  wrote:
>
>> On Thu, Jan 20, 2011 at 00:49, Andrew Morton<akpm@...ux-foundation.org>  wrote:
>>> On Wed, 12 Jan 2011 18:07:23 +0000
>>> Stuart Swales<stuart.swales.croftnuisk@...il.com>  wrote:
>>>> From: Stuart Swales<stuart.swales.croftnuisk@...il.com>
>>
>>>> +static inline int append_filetype_suffix(char *buf, __u16 filetype)
>>>> +{
>>>> + __ __ if ((__u16) -1 == filetype)
>>>
>>> unneeded cast.
>>
>> My compiler tends to disagree. On current mainline, it says:
>>
>> fs/adfs/adfs.h: In function ___append_filetype_suffix___:
>> fs/adfs/adfs.h:115: warning: comparison is always false due to limited
>> range of data type
>>
>
> hm, OK, I'll add a cast.
>
> The code seems a bit fishy - it wants 0xffff but the comment says it's
> handling a 12-bit quantity.  Obviously the all-ones pattern has some
> magical out-of-band meaning here, but it is not explained what that
> meaning *is*.  Perhaps that is described elsewhere.
>


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