Re: libssh and Visual C++ (again)

[Christophe Baribaud <christophe.baribaud@xxxxxxxxx>]

Le 27/09/2012 17:16, Werner Koch a écrit :
> On Thu, 27 Sep 2012 15:01, asn@xxxxxxxxxxxxxx said:
>
> > The sftp functions should simply return an int64_t.
> That would consist an ABI break!
>
> With automake it is easy to insert the right type; cmake should be able
> to do the same.
>
>
> Salam-Shalom,
>
>     Werner
>
>
> p.s. In Libassuan I even wrote a tool to build header files, excerpt
> from the Makefile:
>
>    parts_of_assuan_h = \
> 	posix-includes.inc.h   w32-includes.inc.h \
> 	posix-types.inc.h      w32-types.inc.h \
> 	posix-fd-t.inc.h       w32-fd-t.inc.h  w32ce-fd-t.inc.h \
> 	posix-sock-nonce.inc.h w32-sock-nonce.inc.h \
> 	posix-sys-pth-impl.h   w32-sys-pth-impl.h \
>          w32ce-add.h
>
>    mkheader: mkheader.c Makefile
>    	$(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
>    
>    assuan.h: assuan.h.in mkheader $(parts_of_assuan_h)
>    	./mkheader $(host_os) $(srcdir)/assuan.h.in >$@
>
> and assuan.h.in has code like this:
>
>    #include <stdio.h>
>    @include:sys/types.h@
>    @include:unistd.h@
>    #include <stdarg.h>
>    
> this was easier and more flexible than to do it in configure.  Works
> even with just nmake.
My patch does someting very similar, and is not an ABI break (ssize_t is 
still used under unix/linux platforms). Of course the method used to 
solve the issue doesn't care (I don't espacially want to promote my own 
patch ...)
Windows regression is not an issue, it didn't even compile for a 
while... except if we want binary compatibility with a version of the 
0.5.x branch. Did someone build a 0.5.x version under Windows ?
The reason why I am trying to change ssize_t usage is that it is now 
impossible to link libssh library and wxWidgets library with the same 
program under Windows. I do think that it is an issue we have to deal with.
The minimalistic patch is to provide, under Windows, the same ssize_t 
definition as wxWidgets-2.8 does, but the dependency with wxWidgets seem 
ugly. This is why I suggest to stop using ssize_t, which is not ISO 
standard (unlike size_t) in the API.
If, instead of ssize_t, we use a private type, let it call ssh_ssize_t, 
the type has to be strictly identical to ssize_t under unix/linux (ABI 
compatibility)
Under Windows platforms, it has to be different between WIN32 and WIN64, 
because size_t is different, and it is important to be consistent 
between parameters and return value (the size_t parameter is returned in 
the ssize_t return value in case of success)
An maybe better solution would have been to use an int as a return 
value, -1 in case of error and 0 in case of success, like all other 
functions, and provide a size_t * parameter filled with the number of 
bytes written/read, but it is too late... (API compatibility)
And what happens with platforms like Mac OS ?

Christophe