CODEWITHSUNDEEP
cuthash
zzxyz
zzxyz

Reputation: 2981

Are uthash and utarray backward compatible?

I'm specifically concerned about utarray version 2.0.2 vs. 1.9.6. (The most recent copyrights being 2017 and 2012, respectively).

I need to add uthash.h to an existing project that makes use of utarray.h, and would rather both these headers come from the same version/commit, so I'm considering replacing the older utarray.h with the newer.

I should note I'm not terribly concerned about compile-time incompatibilities, such as name changes and the like. My main concern would be run-time breakages.

Upvotes: 1

Views: 132

Answers (2)

zzxyz
zzxyz

Reputation: 2981

A rare but 100% reproducible stack corruption issue around usage of utarray caused me to attempt an upgrade, of JUST utarray.h, but across the board at my company.

The short answer is NO, it is not 100% backward compatible. But it's very close.

The longer answer is for our applications, the required changes were extremely trivial, basic usage does not change, and the stack corruption issue seems to have gone away. It also seems to be interacting well with other, older headers, such as uthash.

The only interface change I found was a _UNUSED_ macro for hushing gcc warnings changed to UTARRAY_UNUSED. Everything else seems to be bug fixes.

Edit: I'm not naive enough to be even remotely confident that 1.9.6 had an issue causing our stack corruption, but I'm not totally dismissing the possibility after carefully stepping through the same 10 lines of code in the debugger for about 2 hours, and watching every variable be correct.

Upvotes: 0

nemequ
nemequ

Reputation: 17492

If you look at utarray.h, you'll see that all it defines are macros, a few static functions, and some typedefs; there are no public symbols, so everything should be restricted to the current compilation unit.

In other words, yes, as long as you don't include both headers in the same file (which would likely cause a compile-time error) or expose it in your public API you should be safe.

That said, the answer to the question in your title is "no"; incompatible changes in the API break backward compatibility. But with the restrictions you mention in the body you should be okay.

Upvotes: 1

Related Questions