On 12/17/06, Frank Zago <fr...@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
