Is this "Invalid union access“ reported by Coverity valid ? Does it pose any real issue ?

[randy-xiang]

Hi all,

Our static code analysis tool Coverity reported multiple instances of "Invalid union access" issues. These were not reported before so I guess it's newly supported recently after we upgrade the scan tool.

See below screenshot. We're using version 3.11.3

I wish to know whether these reports pose any real risk in runtime ? Forgive me, I had a hard time reading and understand the source, so I wish if someone who's familiar with the design could assist my question ?

Thanks a lot in advance !

• Randy

[dingminghbut]

I would treat this as likely a false positive unless Coverity gives a concrete path where the stored type tag and the accessed union member can really diverge.

nlohmann::json intentionally uses a tagged-union style representation. The important invariant is that the active member in m_value is determined by m_type — for example, object values use m_value.object, arrays use m_value.array, strings use m_value.string, and so on. Destruction/copy/move paths switch on the stored value_t and then access the corresponding union member.

That pattern is valid when the tag invariant is preserved, but it is also a common source of static-analysis warnings because analyzers may not be able to prove that every access is guarded by the same tag that constructed the active member.

So my practical read is:

• If your code only uses the public nlohmann::json API and does not corrupt/move/use-after-destroy JSON values, this does not by itself indicate a runtime problem.
• If Coverity provides a specific CID/path where m_type is changed before the old union member is accessed, that individual path is worth inspecting.
• If possible, also run your relevant tests with ASan/UBSan; a real invalid union/lifetime issue should usually show up there more concretely than as a broad structural warning.
• Since you are on 3.11.3, it is also worth checking the latest release before suppressing the findings, just in case one of the reported paths was improved since then.

If the CIDs all point to the normal m_type/m_value storage and destroy/copy logic, I would document/suppress them as intentional manual tagged-union lifetime management rather than treating them as exploitable runtime bugs.

[randy-xiang]

Thank you for the prompt response!
Indeed we're using the public APIs, our past test record didn't show any issue related to json so I guess the risk is low.

I will take your advice to upgrade to latest rev and scan/test again.

[nlohmann]

@dingminghbut Thanks for the quick and thorough response. We added the assert_invariant() calls a while back to make sure that all accesses to the union are correct.

[nlohmann]

Followed up on this and traced the tagged-union invariant through the source (constructors, json_value::destroy(), copy/move constructors, swap(), get_ref/get_ptr): m_type and the active m_value member are always set, destroyed, and swapped together as a pair — there's no path where they can diverge. assert_invariant() is exactly the invariant-checking mechanism for this. So @dingminghbut's read is confirmed: these are known false positives from Coverity's generic hand-rolled-tagged-union heuristic, safe to suppress/document rather than chase further.

(Drafted by Claude Code.)