gpgme_data_seek with SEEK_END on memory-based data fails

[Leo Gaspard]

First of all, sorry for having been late answering.

On 30/07/2012 18:28, Werner Koch wrote:
> On Mon, 30 Jul 2012 12:42, ekleog at gmail.com said:
>
>> So, I suppose the patch I sent on the mailing list yesterday doesn't work ?
>
> I have not said this ;-).  I have two problems with the patch:
>
>   - It is very specific for keyservers and not a general way to describe,
>     well, what keyservers are.  We already have ways to locate keys from
>     remote resources.  See the GPGME_KEYLIST_MODE_* flags.  This needs to
>     be unified with other uses of the keys.  And it also needs to be in
>     line with planned or already done changes in 2.1.

Yes, I saw GPGME_KEYLIST_MODE_* flags. But there are no way of selecting the 
keyserver to use directly from GPGME. So the only way would be to modify 
gpg.conf before each operation ?

That's why I thought a keyserver (i.e. the server with which to interact, maybe 
another name could be better ? I used OpenPGP name, because I don't know GPGSM 
enough yet.) setting could be useful.

>   - You break the ABI and API with your patch - this is not acceptable
>     for a stable library.

I thought quite a bit about this, and didn't find out in which way.

Summarizing the changes :

  * context.h : Added a keyserver variable to struct gpgme_context. As the 
structure is fully opaque from the library user, I don't think it breaks any 
API. (except maybe the internal one ?) And, as it is referred from "user" code 
only through pointers, there is no ABI breakage, right ?

  * engine-backend.h ; engine-gpg.h ; engine-gpg.c ; engine-gpgsm.c ; engine.c ; 
engine.h ; export.c ; keylist.c : Some small API change, but it's only on 
internal functions, it's not an issue, is it ?

  * gpgme.c : The only externally-visible API change : adding 
gpgme_set|get_keyserver. The objective of the patch

Am I wrong ?

Cheers,

Leo