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

[Marcus Brinkmann]

On Fri, May 02, 2003 at 09:23:37PM +0200, Jann Fischer wrote:
> 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:

[...]

> 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?

Right, the interface has changed.  The semantics of gpgme_data_read now
match exactly the semantics of read() for file handles.  So, the size of
the underlying data is not readily available right now.  There are several
things you can do, and one thing I can do:

1. For memory based objects, use gpgme_data_release_and_get_mem ().
Chances are that memory based objects are those you are concerned about.
The advantage is that you save yourself a copy of the data.  The
disadvantage is that this only works for memory based objects.

2. Use gpgme_seek.  You can seek to the end of the data, and the return
value is the offset (use SEEK_END and 0).  Then you have to seek back to the
beginning and read the data.  This will work for all file based and memory
based data objects, and possibly for user implemented objects if they
provide the seek function.

3. I could add a gpgme_stat function that provides more information about
the underlying object.  I was thinking about that anyway.

Without having 3, I would suggest to use 1 if you know that it'sa memory
object, and 2 otherwise.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/