On Sunday 30 September 2012 17:07:43 Christophe Baribaud wrote:
> Le 30/09/2012 12:01, Andreas Schneider a écrit :
> > On Saturday 29 September 2012 14:13:48 Bernhard R. Link wrote:
> >> * Werner Koch <[email protected]> [120927 14:11]:
> >>> On Wed, 26 Sep 2012 20:58, [email protected] said:
> >>>> file, but is it a good practice to have an installed header file whose
> >>>> content varies from an architecture to another?
> >>>
> >>> Yes, that is imho fine and much easier to maintain than fragile
> >>> #ifdefs. Some libraries install a generic file and one system specific -
> >>> which is a similar approach.
> >>
> >> #ifdefs might be fragile, but non-generic header files are quite
> >> fragile, too, and can have ugly side-effects with cross-compiling
> >> and other cases. As long as there is a specific case like working
> >> around some very unusual environment, just checking for that with
> >> an ifdef can be quite a robust solution.
> >
> > ssize_t under unix with large file support is a uint64_t. I think if we
> > replace the ssize_t in these two sftp function with uint64_t it will not
> > be an API breakage on unix and probably not a ABI breakage too.
> >
> > A generated config.h as a public header is a no-go.
> >
> > -- andreas
>
> I think you mean int64_t. The return value shall by a signed type.
> uint64_t is unsigned.
Yes, I did. Sorry
> Replacing ssize_t by int32_t is an ABI breakage under 64 bits platforms
Yes.
> Replacing ssize_t by int64_t is an ABI breakage under 32 bits platforms
No, cause we compile with lfs (large filesystem support) and then ssize_t is a
64bit integer.
-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
www.cryptomilk.org [email protected]
