Page MenuHome GnuPG
Create Task
Maniphest T766

gpgme_data_rewind is deprecated
Closed, ResolvedPublic
Actions

Description

Hi,

It would be nice if gpgme_data_rewind could get un-deprecated.

The reason for asking about it is:

the gpgme manual mentions 2.3 Largefile Support (LFS), and how the application
should get compiled with largefile support.
However my application (Claws Mail) isn't compiled with largefile support, and
we'd like to avoid that as much as possible because doing so would change
structure sizes and break binary compatibility with the binary caches we have.

From gpgme's manual, if the app isn't compiled with largefile support, we must
be aware of issues with off_t size changing and file descriptors.

We manage to avoid the file descriptor issue because we only use gpgme with data
coming from memory, and we manage to avoid the off_t issue by not using
gpgme_data_seek or other functions using off_t's. The only places where's we'd
need to gpgme_data_seek is to seek-set to 0; hence, we do that with
gpgme_data_rewind(), which, being compiled in gpgme, uses the correct size of
off_t...

So it'd be a real convenience for us if this function was un-deprecated, as
that'd remove the fear of having this function removed from our heads :)

Thanks,
Colin

Details

Due Date
Mar 10 2007, 1:00 AM

Event Timeline

colinleroy added projects: Feature Request, gpgme.Feb 22 2007, 2:38 PM
colinleroy added a subscriber: colinleroy.
• werner assigned this task to marcus.Feb 23 2007, 6:45 PM
• werner added subscribers: marcus, • werner.
• werner set Due Date to Mar 10 2007, 1:00 AM.Mar 5 2007, 4:01 PM
marcus added a comment.Apr 12 2007, 1:20 AM

Hi,

I have sympathy with you, and if gpgme_data_seek were the only user of off_t in
the GPGME API, there would be some force behind your suggestion. However, it
isn't, and I don't think that keeping around multiple interfaces for essentially
the same function is useful in the long run. That said, I have two things that
may help you:

  1. I have no intention to remove the deprecated interfaces anytime soon.

Removing them would constitute an ABI and API break, and we have no intention to
introduce such breaks needlessly. Certainly it won't be removed before such an
ABI/API break has to be done anyway for other reasons, and possibly it won't be
removed before the next major revision (ie, 2.0), which is not on the horizon at
the moment. So, for the foreseeable time, you are ok.

  1. It should be a trifle matter to implement your own wrapper in its own C file

which defines _FILE_OFFSET_BITS to 64 and LARGEFILE_SOURCE to 1 before including
any header file. It should be feasible to do this without any major changes to
your configuration or build rules. Together with the other precautions you are
taking (don't forget to document those :), you should be fine. If this is not
feasible, I would like to learn about the reasons for that. Personally, I
prefer this way to resolve this, because it puts the kludge together with the
other kludges (avoiding certain interfaces) and makes more of the internal and
external dependencies explicit in the code.

Does this resolve your concerns?

Thanks,
Marcus

marcus added a comment.May 19 2007, 10:40 PM

I put the status to deferred, as the final decision to keep or remove
gpgme_data_seek will be done when the other deprecated interfaces will be removed.

marcus added a project: Stalled.May 19 2007, 10:40 PM
• werner added a comment.Jun 17 2009, 4:28 PM

Marcus, I think we can close this now.

gpgme now tests for the correct off_t and thus Claws needs to use the correct
off_t anyway.

marcus closed this task as Resolved.Aug 13 2009, 3:17 PM

Quite right, claws actually does invoke AC_SYS_LARGEFILE.

marcus removed a project: Stalled.Aug 13 2009, 3:17 PM