Issue in printing values when using `TEST_ASSERT_EQUAL_UINT8_ARRAY`

[wm-eisos]

Description

There is an issue with using TEST_ASSERT_EQUAL_UINT8_ARRAY since it will internally attempt to print the mismatching values as shown

Unity/src/unity.c

Lines 958 to 965 in 0d7ea70

	UnityTestResultsFailBegin(lineNumber);
	UnityPrint(UnityStrElement);
	UnityPrintNumberUnsigned(num_elements - elements - 1);
	UnityPrint(UnityStrExpected);
	UnityPrintIntNumberByStyle(expect_val, style);
	UnityPrint(UnityStrWas);
	UnityPrintIntNumberByStyle(actual_val, style);
	UnityAddMsgIfSpecified(msg);

however that call should depend on whether its a uint or int similar to what was done here #784

[avitase]

I can reproduce this as well. I stumbled upon the same problem while debugging a failing TEST_ASSERT_EQUAL_UINT8_ARRAY(...): the failure reports the correct element index, but prints nothing between Expected and Was. However, in my setup this is not limited to the _UINT8_ array macro. I see the same "blank value" output for:

• TEST_ASSERT_EQUAL_UINT8_ARRAY(...)
• TEST_ASSERT_EQUAL_HEX8_ARRAY(...)
• TEST_ASSERT_EQUAL_MEMORY(...)

Here is a minimal example that produces the broken output:

#include "unity.h"
#include <stdint.h>

void setUp(void)
{
}

void tearDown(void)
{
}

void test_uint8_array(void)
{
    const uint8_t expected[4] = {0x11, 0x22, 0x33, 0x44};
    const uint8_t actual[4] = {0x11, 0x22, 0x33, 0x55};

    TEST_ASSERT_EQUAL_UINT8_ARRAY(expected, actual, 4);
}

void test_hex8_array(void)
{
    const uint8_t expected[4] = {0x11, 0x22, 0x33, 0x44};
    const uint8_t actual[4] = {0x11, 0x22, 0x33, 0x55};

    TEST_ASSERT_EQUAL_HEX8_ARRAY(expected, actual, 4);
}

void test_memory(void)
{
    const uint8_t expected[4] = {0x11, 0x22, 0x33, 0x44};
    const uint8_t actual[4] = {0x11, 0x22, 0x33, 0x55};

    TEST_ASSERT_EQUAL_MEMORY(expected, actual, 4);
}

int main(void)
{
    UNITY_BEGIN();

    RUN_TEST(test_uint8_array);
    RUN_TEST(test_hex8_array);
    RUN_TEST(test_memory);

    return UNITY_END();
}

Observed output (values missing):

$ gcc test.c unity.c && ./a.out
test.c:17:test_uint8_array:FAIL: Element 3 Expected  Was 
test.c:25:test_hex8_array:FAIL: Element 3 Expected  Was 
test.c:33:test_memory:FAIL: Memory Mismatch. Byte 3 Expected  Was 

-----------------------
3 Tests 3 Failures 0 Ignored 
FAIL

[rstahn]

Looking at unity.c there are currently two function:

• UnityPrintIntNumberByStyle() will only produce output for style UNITY_DISPLAY_RANGE_INT
• UnityPrintUintNumberByStyle() will only produce output for style UNITY_DISPLAY_RANGE_UINT

Instead of modifying UnityAssertEqualIntArray() to call either UnityPrintIntNumberByStyle() or UnityPrintUintNumberByStyle() (like it is done in UnityAddMsgIfSpecified()) it might be more useful to merge UnityPrintIntNumberByStyle() and UnityPrintUintNumberByStyle() into a generic function (e.g. UnityPrintNumberByStyle()) again, which is able to handle different styles. However the first question to me is, why these functions are separated right now. This will need further investigation.

Moreover I wonder, why the unit tests do not catch the incomplete output from the above minimal example. Would be probably a good idea to improve the test coverage for that case first.

[rstahn]

UnityPrintUintNumberByStyle() will only produce output for style UNITY_DISPLAY_RANGE_UINT

This is actually not true. UnityPrintUintNumberByStyle() will also produce output if the style is not UNITY_DISPLAY_RANGE_UINT:
It will print the values in HEX in this case (regardless whether UNITY_DISPLAY_RANGE_HEX is specified or not).
Thus merging UnityPrintIntNumberByStyle() and UnityPrintUintNumberByStyle() is not as simple as it did look like at first glance...

[mvandervoord]

The two functions were once one function, but to avoid compilers complaining about casting back and forth between signed and unsigned values, it was eventually split to avoid all the warnings.

Back on the original issue brought up: are you both running on an ARM platform? I'm wondering if the problem is because of alignment when attempting to print?

[avitase]

Back on the original issue brought up: are you both running on an ARM platform? I'm wondering if the problem is because of alignment when attempting to print?

I am running it on x86-64

[mvandervoord]

Interesting. What else can you tell me about your system? (OS? toolchain? etc). I'd like to try to reproduce the issue.

[avitase]

Interesting. What else can you tell me about your system? (OS? toolchain? etc). I'd like to try to reproduce the issue.

Ubuntu 25.10, gcc 15.2.0, and glibc 2.42 (on x86_64)

[loopj]

I am also able to reproduce this issue on macOS:

❯ gcc --version
Apple clang version 17.0.0 (clang-1700.6.3.2)
Target: arm64-apple-darwin25.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Seeing FAIL: Element 0 Expected Was when using TEST_ASSERT_EQUAL_HEX8_ARRAY

[mvandervoord]

@loopj -- ARM makes sense... this was my original theory. We'll have to change the way we're printing those values to move them to a 64-bit boundary before printing.

[mvandervoord]

Added output validation to the tests to detect when this is happening. Now we "just" have to fix it. ;)