Including gpgme.h fails with i686-mingw-w64
Werner Koch
wk at gnupg.org
Wed Apr 6 10:13:16 CEST 2011
On Tue, 5 Apr 2011 18:43, aheinecke at intevation.de said:
> I understand your point about making as few assumptions as possible and
> defining your own types. But wouldn't it then be better named gpgme_ssize_t ?
We once changed the gpgme data functions to be similar to the standard
IO functions. Thus we need ssize_t and can't use a custom type - such a
custom size would shift the problem to the application which needs to
see how to match gpgme_size_t and the standard ssize_t. The whole point
of the API change was to make using gpgme easier.
> Can there be a check if ssize_t is already defined instead of having a
> conflicting definition of a system type in a header file?
There should be one but wait ... I just checked and noticed that it is
hardwired in gpgme.h. For other types, like socklen_t we use a
configure test.
Having said this, I reconsider and will add a configure test. Thus if
gpgme and the application are built on the same platform (or under
Windows the same version of the toolchain), it should work. Libgcrypt
also needs it.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel
mailing list