[
https://issues.apache.org/jira/browse/HADOOP-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641037#comment-14641037
]
Colin Patrick McCabe commented on HADOOP-11505:
-----------------------------------------------
Thanks, [~alanburlison]. Your change is a great improvement.
In {{Buffers.h}}:
{code}
uint32_t lengthConvertEndium() {
uint64_t value = hadoop_be64toh(*((uint64_t *)this));
...
{code}
This looks very wrong. I suppose it's going to typecast the structure to a
long\* and then dereference that? I suppose it will do "something" as long as
the compiler packs keyLength and valueLength into a single 8-byte region. I
suppose this is an existing problem. If you can't fix it here, can you create
a JIRA?
I would like to +1 this, but I'm concerned that this change hasn't been tested.
Although I think your change is absolutely correct, I'm concerned that we
might expose a bug. Can you do a quick test on this?
> hadoop-mapreduce-client-nativetask uses bswap where be32toh is needed,
> doesn't work on non-x86
> ----------------------------------------------------------------------------------------------
>
> Key: HADOOP-11505
> URL: https://issues.apache.org/jira/browse/HADOOP-11505
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Labels: BB2015-05-TBR
> Attachments: HADOOP-11505.001.patch, HADOOP-11505.003.patch,
> HADOOP-11505.004.patch
>
>
> hadoop-mapreduce-client-nativetask fails to use x86 optimizations in some
> cases. Also, on some alternate, non-x86, non-ARM architectures the generated
> code is incorrect. Thanks to Steve Loughran and Edward Nevill for finding
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
