Android 在jni中返回错误的md5哈希

我正在尝试使用原始/未接触的MD5.h和md5c.c（github源文件：）为字符串生成MD5哈希。但我的结果在任何时候都不正确。当我使用三星galaxy j设备进行测试时，我的结果是正确的。但当我使用三星galaxy s7设备进行测试时，我的结果是错误的。我的代码出了什么问题？你有什么解决这个问题的建议吗？谢谢你的支持

这是我的项目：

我使用cmake配置jni库：

cmake_minimum_required(VERSION 3.4.1)

set(MD5SOURCES
    src/main/cpp/md5.c)


add_library(native-lib
             SHARED
             src/main/cpp/native-lib.cpp
              ${MD5SOURCES})


find_library(log-lib
              log )

target_link_libraries(native-lib
                       ${log-lib} )

这是本机库：

#include <jni.h>
#include <string>
#include "md5.h"

extern "C"
jstring
Java_test_sinhpn_md5test_MainActivity_stringFromJNI(JNIEnv *env, jobject /* this */, jstring data) {
    char *cstr = (char *) (env)->GetStringUTFChars(data, 0);

    MD5_CTX context = {0};
    MD5Init(&context);
    MD5Update(&context, (unsigned char *) cstr, strlen(cstr));
    unsigned char dest[16] = {0};
    MD5Final(dest, &context);
    env->ReleaseStringUTFChars(data, cstr);

    int i;
    char destination[32] = {0};
    for (i = 0; i < 16; i++) {
        sprintf(destination, "%s%02x", destination, dest[i]);
    }
    return env->NewStringUTF(destination);
}

这是我测试的结果：

---

这两部手机使用不同的ARM指令集。 Galaxy J使用armeabi-v7a，而S7使用arm64-v8a

根据上述构建的cmake正在为所有体系结构生成.so文件，这会导致问题，因为本机代码中存在32位与64位强制转换问题

但是，在您的案例中存在一个简单的修复。您可以将构建限制为默认配置中的“armeabi-v7a”、“armeabi”，如下所示

    externalNativeBuild {
        cmake {
            cppFlags "-frtti -fexceptions"
            abiFilters "armeabi-v7a", "armeabi"
        }
    }

---

这应该仍然有效，因为arm64v8a向后兼容较旧的v7a体系结构。

我通过替换解决了我的问题：

typedef无符号长整数UINT4在md5.c->
typedef uint32\u t UINT4中

我在两台设备上再次测试，效果良好。在64位机器上，长int（通常）为64位而不是32位，因此有必要验证行为差异是否可归因于第三方MD5库中的缺陷。我建议在C源代码中显式（和数字）表示的几个字节序列上测试该库，以确认它在两个系统上产生相同的结果
在64位平台上使用64位
long
值时，这是不正确的…@John Bollinger:谢谢你的评论。我理解你的建议，我必须用几个字节，而不是字符串来测试？安德鲁·亨勒：谢谢你的评论。那么我的md5库错了吗？你能为我分享好的md5代码吗？@PhanSinh你找到解决方案了吗？你能提到如何解决这个问题吗？架构差异是一个重要的观察结果，但是你在本机代码中看到任何实际的强制转换问题，或者这部分是推测性的吗？@Bharat Kumar Molleti：谢谢你的评论。“但这是行不通的。”约翰伯林格请看上面安德鲁的评论。/*UINT4定义一个四字节字*/typedef无符号长整数UINT4；在具有64位长值的64位平台上，这是不正确的…，存在上述问题建议谨慎处理此类转换和强制转换。@BharatKumarMolleti，因此这确实是推测性的，但您的推测结果是正确的？我赞扬你的洞察力。但是，如果它指出了问题代码的实际问题，而不是猜测问题的一般性质，那么它会是一个更好的答案；现在它看起来像是typedef unsigned int UINT4，现在工作了，谢谢你把我移到了正确的方向
    externalNativeBuild {
        cmake {
            cppFlags "-frtti -fexceptions"
            abiFilters "armeabi-v7a", "armeabi"
        }
    }