怪异的系统时间获取宏OsixGetSysTime：是否存在隐藏作用？

Great question—this seemingly useless macro is likely a holdover from platform-specific code or a clever hack to handle compiler/API edge cases. Let’s break down the most plausible reasons it exists:

1. Compiler Barrier (Prevent Instruction Reordering) #

Even though *a = *a looks like a no-op, most compilers won’t optimize this operation away because it involves explicit memory reads and writes. In older compilers (or environments without standard memory barrier intrinsics like __sync_synchronize()), this serves as a poor-man’s compiler barrier.

In your code example:

OsixGetSysTime (&u4Ticks);
u4Ticks -= gu4TicksCorr;

The macro ensures the compiler doesn’t reorder the read of gu4TicksCorr before the "time retrieval" step. This is critical if gu4TicksCorr is updated by another thread or interrupt—barriers prevent the compiler from optimizing away the logical ordering of these operations.

2. API Compatibility (Preserve Code Structure) #

It’s highly likely this macro was originally implemented to read a system tick register or hardware clock (e.g., #define OsixGetSysTime(a) (*a = READ_SYS_TICK_REG())). When the system time retrieval logic changed (or was moved to a different part of the codebase), replacing the macro with a no-op allowed all existing calls to OsixGetSysTime to remain unchanged.

This saves developers from modifying every instance of the macro across the codebase, maintaining backward compatibility while updating the underlying timekeeping implementation.

3. Avoid Uninitialized Variable Warnings #

Local variables like u4Ticks in UtlGetTime are not automatically initialized. Without the macro, the line u4Ticks -= gu4TicksCorr would trigger a compiler warning (or error, depending on settings) about using an uninitialized variable.

The self-assignment *a = *a tricks the compiler into thinking u4Ticks has been assigned a value, suppressing these warnings. While this is a hacky way to fix the issue, it’s common in legacy code where refactoring to properly initialize variables would be more effort.

4. Volatile Semantics for Hardware Registers (Potential Original Use) #

If the macro was designed to accept pointers to volatile memory (e.g., memory-mapped hardware registers), *a = *a would force a read from the register followed by a write (though writing to a read-only clock register might be harmless). Even though your current code passes a pointer to a local non-volatile variable, the macro’s original design might have accounted for hardware interactions.

内容的提问来源于stack exchange，提问作者CIsForCookies