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.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Some lines end up being too long, but I don't know what libxl's approach
would be to avoid this. Plus the libjson-c counterparts have similar line
length issues.

--- a/tools/include/libxl_json.h
+++ b/tools/include/libxl_json.h
@@ -28,10 +28,9 @@
 #endif
 #endif
 
+#ifdef _hidden /* Don't expose internal function decls. */
+
 #ifdef HAVE_LIBJSONC
-#ifndef _hidden
-#define _hidden
-#endif
 _hidden int libxl__uint64_gen_jso(json_object **jso_r, uint64_t val);
 _hidden int libxl_defbool_gen_jso(json_object **jso_r, libxl_defbool *p);
 _hidden int libxl_uuid_gen_jso(json_object **jso_r, libxl_uuid *p);
@@ -44,20 +43,24 @@ _hidden int libxl_hwcap_gen_jso(json_obj
 _hidden int libxl_ms_vm_genid_gen_jso(json_object **jso_r, libxl_ms_vm_genid *p);
 #endif
 #if defined(HAVE_LIBYAJL)
-yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val);
-yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
-yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
-yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
-yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, libxl_bitmap *p);
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                                 libxl_cpuid_policy_list *p);
-yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
-yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
-                                              libxl_key_value_list *p);
-yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
-yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand, libxl_ms_vm_genid *p);
+_hidden yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val);
+_hidden yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
+_hidden yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
+_hidden yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
+_hidden yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, libxl_bitmap *p);
+_hidden yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                                         libxl_cpuid_policy_list *p);
+_hidden yajl_gen_status libxl_string_list_gen_json(yajl_gen hand,
+                                                   libxl_string_list *p);
+_hidden yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
+                                                      libxl_key_value_list *p);
+_hidden yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
+_hidden yajl_gen_status libxl_ms_vm_genid_gen_json(yajl_gen hand,
+                                                   libxl_ms_vm_genid *p);
 #endif
 
+#endif /* _hidden */
+
 #include <_libxl_types_json.h>
 
 /* YAJL version check */

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

On 27.11.2025 15:27, Anthony PERARD wrote:
> 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`.

But xl doesn't use any of them, ...

> libxl_json.h is only part of the header, there's a second part that is
> automatically generated, _libxl_types_json.h.

... it only uses something from that generated header (which isn't being
altered here).

Jan