[sane-devel] [Patch][Resend] Native Win32 support

[Ilia Sotnikov]

On 12/17/06, Frank Zago <frank at zago.net> wrote:
> Hello Ilia,
>
> I have a few commetns on your patches.
>
> Overall it looks ok, although I haven't tested it nor applied it.
>
> * the following prototypes look incorrect
> +#if OS_WIN32
> +typedef int PASCAL (*WireReadFunc) (SANE_SOCKET fd, char * buf, int
> len, int flags);
> +typedef int PASCAL (*WireWriteFunc) (SANE_SOCKET fd, const char * buf,
> int len, int flags);
> +#else
>
> Is there a reason they differ from unix ? Specifically the return code
> and the type of buf.
>
> * no need for some ifdefs in net.c
> +#if OS_WIN32
> +      if (dev->ctl == INVALID_SOCKET)
> +#else
>        if (dev->ctl < 0)
> +#endif /* OS_WIN32 */
>
> Just get rid of the second case. There is a few of these.
>

Good afternoon, Frank! Thank you for comments.

About difference in the recv/send prototypes - all Win32 API functions
declared as having __stdcall attribute - Pascal calling convention
(thus PASCAL is mentioned). Symbol names according to the convention
depend on function arguments. When we would use the same prototypes
under Win32 as under Unix, then all imported symbols would have
__cdecl attribute, which means that we would either get unresolved
symbols during link phase, or compiler (hopefully, gcc supports that
with --enable-stdcall-fixup) would need to implement some intelligence
to find correct symbol name. I decided to make the picture cleaner by
using different prototypes.

And regarding error handling after calling socket related functions -
under Win32 SOCKET type (first argument, fd, for most of the above
mentioned functions) is unsigned, which means that condition 'less
than 0' is meaningless for it and comparision will always be true.
Perhaps, it would be cleaner to use a macro there, but I'm not sure. Any ideas?

Best regards,
-- 
 Ilia Sotnikov