On Tue, Nov 25, 2025 at 10:11:21AM +0100, Jan Beulich wrote: > Ideally internal function declarations wouldn't live in a non-private > header. If already they need to, they should be hidden as much as > possible. That is (a) their declarations shouldn't be exposed and (b) the > symbols shouldn't appear in the shared library's dynamic symbol table. > Gate the declarations upon _hidden actually being defined (rather than > providing an empty fallback), and apply _hidden also to the libyail > variants.
The YAJL functions needs to stay in the API, they've been exposed on purpose in this header... The only user of those I know is `xl`. They are limited since your application also needs to use libyajl. I think I've butchered this header enough to make it complicated to use for applications that are not `xl`. libxl_json.h is only part of the header, there's a second part that is automatically generated, _libxl_types_json.h. While we could simply move the few prototype that uses json-c support listed here to an actually private header, there's still the autogenerated header to deal with. I feel like it would simpler to avoid installing both headers (libxl_json.h and _libxl_types_json.h) when we compile the tools with json-c. And even maybe add a fake "libxl_json.h" which only have an "#error" saying the json helper aren't available anymore. Thanks, -- Anthony PERARD
