I came from it with stuffing the vector into a QByteArrayView - and then comparing it with the same string being roundtripped thru a copy/paste operation by the user.

I explicitly keep the null byte so that you can simply pass the (pointer to the data of the) vector of bytes to the std::string c'tor. Meh! The c'tor wants const char *, but the vector is const unsigned char * so that one has to reinterpret_cast.

I don't think the trailing zero-byte should survive the conversion to c++ datastructures.

I have documented the function. The documentation is essentially a copy of the documentation of gpgme_op_random_bytes which should make clear that the function essentially behaves like gpgme_op_random_bytes (except that the gpgmepp function creates a buffer instead of taking one).

I guess it would have been better gpgmepp API to add an additional function for getting 30 zbase32 bytes and to omit the mode flag in the generateRandomBytes function instead of mirroring the API of gpgme.

I don't consider this a bug in gpgmepp's code. gpgmepp behaves exactly like gpgme (because it simply calls gpgme_op_random_bytes after creating a buffer of the requested size). With zbase32 you get 30 bytes zbase32 code and, if you requested more bytes, you get uninitialized additional bytes (which happen to be nullbytes, but that's more accidental than intentional). If anything then the problem is that gpgmepp's API is in general un(der)documented.

Yeah. It's a gpgmepp bug.

I can't speak for gpgmpp but for gpgme. And the gpgme manual says:

Fixed. Thanks for the report!