Is there a logical bug in the log_msg use case?

[dongl-alibaba]

ZTEST(log_msg, test_log_msg_fp)
{
	if (!(IS_ENABLED(CONFIG_CBPRINTF_FP_SUPPORT) && IS_ENABLED(CONFIG_FPU))) {
		return;
	}

#undef TEST_MSG
#define TEST_MSG "%d %lld %f %p %f %p"

	static const uint8_t domain = 3;
	static const uint8_t level = 2;
	const void *source = (const void *)123;
	int mode;
	long long lli = 0x1122334455;
	float f = 1.234f;
	double d = 11.3434;
	char str[256];
	int i = -100;

	test_init();

	Z_LOG_MSG_CREATE3(1, mode, 0, domain, source, level, NULL, 0,
			TEST_MSG, i, lli, (double)f, &i, d, source);
	zassert_equal(mode, EXP_MODE(ZERO_COPY));

This program is expecting a return in zero-copy mode (determined at compile time), but the parameters in Z_LOG_MSG_CREATE3 have non-literal parameters (address fetch operation that can only be determined at runtime: &i). Is this a logical error?

[SureshAnnaiah]

@dongl-alibaba As far as I understand it, I don’t think this is a logical error. In this case, the pointer is treated as a scalar value, so it doesn’t affect the ZERO_COPY decision and doesn't dereference the pointer argument.

[dongl-alibaba]

I want to determine whether the ZERO_COPY mode of a prerequisite Z_LOG_MSG_CREATE3 must be determined at compile time.
Because I passed in &i after testing, Z_LOG_MSG_CREATE3 cannot return mode == EXP_MODE(ZERO_COPY), zassert_equal(mode, EXP_MODE(ZERO_COPY)); always fails (returns FROM_STACK mode). But replacing &i with (void*)(uintptr_t)i, Z_LOG_MSG_CREATE3 will use the expected ZERO_COPY mode.
If the ZERO_COPY mode of Z_LOG_MSG_CREATE3 is determined at compile time. That may verify my conjecture that variables on the stack cannot be manipulated during compilation because they do not exist at this time. So it automatically falls back to FROM_STACK mode.
Please correct me if I misunderstood. Thanks.