Re: Non-standard types in public header files

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> I realized I couldn't use the ssize_t module directly in GnuTLS.
>> GnuTLS uses ssize_t in its public header file
>
> Ouch. This is as bad as using 'bool' in public header files.

They are used for function types that are supposed to be compatible
with the POSIX recv and send, which do use ssize_t.  I think some
earlier systems used 'int' as return value for recv/send, and GnuTLS
should work on those systems too.  I don't know whether there are any
such systems left.  But always using 'int' instead of 'ssize_t' seem
wrong, then you may get warnings about prototype incompatibilities on
modern systems that follow POSIX.

>> The problem, of course, is that the installed header file cannot
>> assume a config.h and the HAVE_* stuff.  It should simply work.
>>
>> A naive implementation of this idea would only work with the same
>> compiler as the one used when building the package.
>
> This can be worked around with suitable #ifs.
>
> The bigger problem is that your library is not the only one in the world,
> and if you define ssize_t as 'long' and another library defines it as
> 'int', the user of your library has BIG interoperability problems.

Right.  But our functions need to be compatible recv/send.  What's a
good solution then?

> For this reason, I recommend: just don't do it. In public headers:
> - Instead of 'bool', use 'int' or 'gnutls_bool_t'.
> - Instead of 'ssize_t', use 'long' or 'gnutls_ssize_t'.

This seem equally problematic, since then you would get errors if an
application tried to replace send/recv with the GnuTLS functions, or
supplied send/recv as function pointers to the GnuTLS hooks.

Now that I think about this, one solution may be to avoid defining
ssize_t altogether.  Instead:

@SSIZE_T@ gnutls_record_send( gnutls_session_t session, const void *data, 
size_t sizeofdata);
@SSIZE_T@ gnutls_record_recv( gnutls_session_t session, void *data, size_t 
sizeofdata);

Then automake could substitute in 'int' or 'ssize_t' as appropriate.
But then all the source code would need to be automake generated
too... Ouch.

Thanks.