Can libzip reliably write in zip archives from buffers/memory (not files)?

Question

I am creating an archive dynamically an need to write some binary data dynamically as file entries. I am also using the extra_field API to add more metadata. Unfortunately when I write using source_buffer the data written gets corrupted.

API calls are along the lines of:

const std::string diff; //this is initialized and passed from a function
zip_t z_; //class member initialized before
const std::string f; // name of the virtual file, passed in the function
// use unique_ptr to manage the lifetime of zip_source_t
std::unique_ptr<zip_source_t, void (*)(zip_source_t*)>  p_zf(
    zip_source_buffer_create((const void*)diff.data(), diff.size(), 0, 0),
    [](zip_source_t* p) { if(p) zip_source_free(p); }
);
if (!p_zf)
    throw exception ...;
// write inside archive and initialize the fields
const zip_int64_t idx = zip_file_add(z_, f.c_str(), p_zf.get(), ZIP_FL_ENC_GUESS);
if(-1 == idx)
    throw exception ...;
// write extra field
if(zip_file_extra_field_set(z_, idx, FS_ZIP_EXTRA_FIELD_ID, 0, (const zip_uint8_t*)&metadata, sizeof(metadata), ZIP_FL_LOCAL))
    throw exception ...;

The code above 'works' but then when I read the archive back for the virtual file f I get some garbled values. The metadata (fairly large, 256 bytes) is perfectly stored.

If I replace the zip_source_buffer_create with:

zip_source_buffer(z_, (const void*)diff.data(), diff.size(), 0)

I get the very same garbled data (the size is always as expected, but the content gets polluted). Only if I write a temporary file and then initialize the zip_source_t via filesystem API (i.e. zip_source_file_create) then all is saved fine:

std::unique_ptr<zip_source_t, void (*)(zip_source_t*)>  p_zf(
    zip_source_file_create(tmp_filename, 0, -1, 0),
    [](zip_source_t* p) { if(p) zip_source_close(p); }
);

Am I doing anything wrong? Please note that the lifetime of diff is const within the scope of both zip_source_buffer_create, zip_source_buffer and zip_file_add. Is this a potential bug in libzip? I'm using version 1.7.3 on Ubuntu 22.04 64 bit.