gpgme: gpgme_data_read() in 0.3.x and 0.4.x branches

[Jann Fischer]

Hello list,

I recently began to use the alpha 0.4.x branch of the GpgMe libraries
for developing purposes and stumbled over a problem:

In the 0.3.x branch, I was used to the following piece of code to figure
out how much memory I need to allocate when using gpgme_data_read() to
read from a GpgmeData object into an own buffer:

(Error handling ommited in both examples for readability)

-<snip>-
GpgmeData data;
size_t need, read;
char *buf;

/* [...] */
gpgme_data_read(data, NULL, 0, &need);
buf = malloc(need);
gpgme_data_read(data, buf, need, &read);
if (need != read) /* [...] */
-<snip>-

According to the docs for the 0.3.x, the part for gpgme_data_read()
reads the following:

"If BUFFER is `NULL', the function returns the amount of bytes
available in NREAD without changing the read pointer.  This is not
supported by all types of data objects.  If this function is not
supported, `GPGME_Invalid_Type' is returned."

However, with the interface changes between 0.3.x and 0.4.x, it seems
that in 0.4.x I cannot do the following:

-<snip>-
GpgmeData data;
ssize_t need, read;
char *buf;

/* [...] */
need = gpgme_data_read(data, NULL, 0);
/* need is always zero, this does mean EOF right? */
buf = malloc(need);
read = gpgme_data_read(data, buf, need);
if (need != read) /* [...] */
-<snip>-

In the second example, gpgme_data_read() will always return 0. Is this
expected behaviour, or did I hit a bug in GpgMe? If it is expected
behaviour, is there another comfortable way to retrieve the size of
the GpgmeData object in order to be able to correctly allocate memory
for my buffer?

Any help and/or hints welcome.

Cheers,
Jann

PS: Please include me in Cc: in answers since I'm not (yet) subscribed
to this list.
-- 
Be careful who you follow.
0x6D839821 | FA8C 3663 9906 D8C3 AC16  F7C4 66E0 F351 6D83 9821
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : /pipermail/attachments/20030505/1bea19c6/attachment.bin