Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Fri, 27 Feb 2015 23:20:04 +0000 (UTC)
From: "Thanh Do (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12778370.1425079149000.38765.1425079204733@Atlassian.JIRA>
In-Reply-To: <JIRA.12778370.1425079149000@Atlassian.JIRA>
References: <JIRA.12778370.1425079149000@Atlassian.JIRA>
 <JIRA.12778370.1425079149344@arcas>
Subject: [jira] [Created] (HDFS-7862) Revisit the use of long data type
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Thanh Do created HDFS-7862:
------------------------------

             Summary: Revisit the use of long data type
                 Key: HDFS-7862
                 URL: https://issues.apache.org/jira/browse/HDFS-7862
             Project: Hadoop HDFS
          Issue Type: Sub-task
            Reporter: Thanh Do


We should revisit the places where {{long}} data type is used. In posix, {{long}} takes 4 bytes in 32 bit architecture and 8 bytes in 64 bit. However, in Windows, {{long}} takes 4 bytes no matter what. Because of this, compilation in Windows could finish successfully, but some tests might fail. Additionally compilation in windows will generate many warnings such as "conversion from 'uint64_t' to 'unsigned long', possible loss of data".

We should stick with using {{int64_t}} or {{uint64_t}} instead whenever we expect the variables are signed or unsigned 8-byte long.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)