linux-kernel - Re: [PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch

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: <87h8jo4qzc.fsf@mail.parknet.co.jp>
Date:   Tue, 21 Aug 2018 07:23:35 +0900
From:   OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Jeff Layton <jlayton@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch

Arnd Bergmann <arnd@...db.de> writes:

>>  /* Linear day numbers of the respective 1sts in non-leap years. */
>> -static time64_t days_in_year[] = {
>> +static long days_in_year[] = {
>>         /* Jan  Feb  Mar  Apr  May  Jun  Jul  Aug  Sep  Oct  Nov  Dec */
>>         0,   0,  31,  59,  90, 120, 151, 181, 212, 243, 273, 304, 334, 0, 0, 0,
>>  };
>
> While this is correct, changing it back to a signed 'long' type seems
> rather arbitrary. I tried to pick a type that would be the same on 32-bit
> and 64-bit architectures, the other choice would have been 'u16',
> which saves a few bytes.

Right. However, "long long" on 32bit arch is not same. In this implement
"long long" works though, Some calculation needs libgcc helper (in
kernel, div64 stuff).  I want to avoid it early than later, and I don't
care saving a few memory in here (I would not care if it was u16).

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>