json: Fix uninitialized variables

[tbzatek]

In file included from ../src/nvme/json.c:17:
In function ‘freep’,
    inlined from ‘json_export_nvme_tls_key’ at ../src/nvme/json.c:70:24:
../src/nvme/cleanup.h:24:9: warning: ‘tls_str’ may be used uninitialized [-Wmaybe-uninitialized]
   24 |         free(*(void **)p);
      |         ^~~~~~~~~~~~~~~~~
../src/nvme/json.c: In function ‘json_export_nvme_tls_key’:
../src/nvme/json.c:70:38: note: ‘tls_str’ was declared here
   70 |                 _cleanup_free_ char *tls_str;
      |                                      ^~~~~~~

In function ‘freep’,
    inlined from ‘json_export_nvme_tls_key’ at ../src/nvme/json.c:66:32:
../src/nvme/cleanup.h:24:9: warning: ‘key_data’ may be used uninitialized [-Wmaybe-uninitialized]
   24 |         free(*(void **)p);
      |         ^~~~~~~~~~~~~~~~~
../src/nvme/json.c: In function ‘json_export_nvme_tls_key’:
../src/nvme/json.c:66:39: note: ‘key_data’ was declared here
   66 |         _cleanup_free_ unsigned char *key_data;
      |                                       ^~~~~~~~

In function ‘freep’,
    inlined from ‘json_import_nvme_tls_key’ at ../src/nvme/json.c:37:32,
    inlined from ‘json_update_attributes’ at ../src/nvme/json.c:147:3,
    inlined from ‘json_parse_port’ at ../src/nvme/json.c:177:2,
    inlined from ‘json_parse_subsys’ at ../src/nvme/json.c:212:4,
    inlined from ‘json_parse_host’ at ../src/nvme/json.c:246:4,
    inlined from ‘json_read_config’ at ../src/nvme/json.c:316:4:
../src/nvme/cleanup.h:24:9: warning: ‘key_data’ may be used uninitialized [-Wmaybe-uninitialized]
   24 |         free(*(void **)p);
      |         ^~~~~~~~~~~~~~~~~
../src/nvme/json.c: In function ‘json_read_config’:
../src/nvme/json.c:37:39: note: ‘key_data’ was declared here
   37 |         _cleanup_free_ unsigned char *key_data;
      |                                       ^~~~~~~~

[igaw]

These variable are set in the next line, so the compiler clearly is making things up. Maybe we should just make it the rule to always initialize cleanup variables. Seems to be a recurring theme.

[tbzatek]

These variable are set in the next line, so the compiler clearly is making things up.

True, gcc tends to have very limited line of sight when analyzing actual usage of the code. Clang is much more sane in this regard, no surprise given how LLVM works. Static analyzers are no better with similar number of false positives.