From: Arnd Bergmann <arnd@arndb.de>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
"Yan, Zheng" <zyan@redhat.com>, Sage Weil <sage@redhat.com>,
Ceph Development <ceph-devel@vger.kernel.org>,
"y2038@lists.linaro.org" <y2038@lists.linaro.org>
Subject: Re: [PATCH] include: ceph: Fix encode and decode type conversions
Date: Thu, 18 Feb 2016 17:20:28 +0100 [thread overview]
Message-ID: <12201396.FPdHi0skie@wuerfel> (raw)
In-Reply-To: <CAOi1vP8NycKxd2sp2qMS7AoZxTSnFSGdxOj9_sXU=sykqsR6hw@mail.gmail.com>
On Thursday 18 February 2016 17:02:25 Ilya Dryomov wrote:
>
> If we are going to touch this function at all, let's drop all casts and
> just add a comment along the lines of "the lack of cast/sign-extension
> here is intentional, this function has a counterpart on the server side
> which also lacks cast/sign-extension, etc". To someone who is not up
> on these subtleties, the __u64 cast is going to be more confusing than
> explicit...
We certainly a comment, I was just suggesting to add the cast as well.
Again, it's not the lack of the cast on the server that is important
here, it's whether it gets interpreted as signed or unsigned at the
point where the timestamp is actually used for comparison or
printing. Let me suggest a comment here:
/*
* ceph timestamps are unsigned 32-bit starting at 1970, which is
* different from a signed 32-bit or 64-bit time_t. On 64-bit
* architectures, this gets interpreted as a subset of time_t
* in the range from 1970 to 2106.
* Machines with a 32-bit time_t will incorrectly interpret the
* timestamps with years 2038-2106 as negative numbers in the
* 1902-1969 range, until both kernel and glibc are change to
* using 64-bit time_t.
*/
Arnd
next prev parent reply other threads:[~2016-02-18 16:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 3:01 [PATCH] include: ceph: Fix encode and decode type conversions Deepa Dinamani
2016-02-15 9:04 ` Yan, Zheng
2016-02-15 11:17 ` [Y2038] " Arnd Bergmann
2016-02-16 5:02 ` Deepa Dinamani
2016-02-16 8:56 ` Arnd Bergmann
2016-02-18 6:02 ` Deepa Dinamani
2016-02-18 9:17 ` Arnd Bergmann
2016-02-18 9:35 ` Deepa Dinamani
2016-02-18 11:29 ` Arnd Bergmann
2016-02-18 16:02 ` Ilya Dryomov
2016-02-18 16:20 ` Arnd Bergmann [this message]
2016-02-18 17:22 ` Ilya Dryomov
2016-02-19 10:00 ` Arnd Bergmann
2016-02-19 11:42 ` Ilya Dryomov
2016-02-19 16:30 ` [Y2038] " Arnd Bergmann
2016-03-01 16:18 ` Sage Weil
2016-02-15 12:37 ` Ilya Dryomov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12201396.FPdHi0skie@wuerfel \
--to=arnd@arndb.de \
--cc=ceph-devel@vger.kernel.org \
--cc=deepa.kernel@gmail.com \
--cc=idryomov@gmail.com \
--cc=sage@redhat.com \
--cc=y2038@lists.linaro.org \
--cc=zyan@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.