Re: libssh and Visual C++ (again)

[Andreas Schneider <asn@xxxxxxxxxxxxxx>]

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 <wk@xxxxxxxxx> [120927 14:11]:
> >>> On Wed, 26 Sep 2012 20:58, christophe.baribaud@xxxxxxxxx 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                asn@xxxxxxxxxxxxxx