I would expect some test case(s) in test/test.c showing expected behaviour.

The fix is more complicated. The strings could be short and still equal as per strncmp(3). E.g. strncmp("abc", "abc", 10).

A better fix is:

if ((s1 == NULL) ^ (s2 == NULL))
    return 1;
if (s1 == NULL) {
    test_fail_string_message(NULL, file, line, "string", st1, st2, "!=", NULL, 0, NULL, 0);
    return 0;
}

if (strncmp(s1, s2, n1 > n2 ? n2 : n1) == 0) {
    test_fail_string_message(NULL, file, line, "string", st1, st2, "!=",
                             s1, OPENSSL_strnlen(s1, n1),
                             s2, OPENSSL_strnlen(s2, n2));
    return 0;
}
return 1;

Still, I think that this test is broken. Two lengths just doesn't make any sense. There should only be one length passed in being the length to be passed to strncmp.

The _ne version is not currently used and the _eq is only called in one place where the lengths differ (test_text in test/endecode_test.c).

My suggestion would be to make both functions only take one length argument and to fix the one caller.

I’ve added some test cases to cover the edge scenarios discussed.

I didn’t change test_strn_eq because in its only usage context, it seems to behave as expected. I fixed test_strn_ne as requested, and I believe it is now correct.

I also realized that test_strn_ne will fail a test if the two strings are equal up to the shorter length, even if they differ later. I think that makes sense: from the test function’s point of view, the behavior beyond the shorter length is undefined, so failing in that case is acceptable.

I also noticed that test_strn_eq != !test_strn_ne currently. If needed, I can update test_strn_eq so that it is fully consistent with test_strn_ne. Let me know if you want me to do that and how you would like the test case results to behave.

Also thank you for the support!

I've done an alternative in #29627 that solves this problem by dropping the second length argument.

Given that the alternative PR has the required approvals, I'm going to close this one.
Despite this, thanks for the submission. It provoked some interesting discussions.