lkml.org 
[lkml]   [2018]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch
Date
Arnd Bergmann <arnd@arndb.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@mail.parknet.co.jp>

\
 
 \ /
  Last update: 2018-08-21 00:23    [W:0.067 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site