Thanks for replying.You may already have received another much bigger patch which I have sent through another email address. You may discard that one then. To your suggestion, here I attached another one which break down the patches per source file (sorry can't make those per problem) and using the diff -u format. In addition to the original smaller fixes and warning fixes (more on those later), this bigger one really offers one new feature: build windows dlls.
Changes summary:1. Enhanced neon.mak to build dlls. And figured the compiler option changed is actually backward compatible with vc6. So the makefile can now be used for all vc6, vs2003 and vs2005. Use of _CRT_SECURE_NO_DEPRECATE is mainly to suppress a lot (too many I think) of warnings from vs2005. It may be nice to clean all these warnings properly for vs2005 but definitely that would introduce a lot of conditional compile specfic to vs2005. That's not nice then. 2. Introduced macros NEON_API and NEON_LINKAGE (in ne_defs.h) to export/import entry points for windows dlls. The macros do nothing for non-Windows platforms and when building neon as static library. 3. All exported functions return types are now enclosed using the NEON_API macro. That's why the patch is big. All headers need to be changed btw. 4. All exported global variables (just a few though) are prefixed with the NEON_LINKAGE macro. 5. ne_free() is made as a proper function for dll. As if poeple have their own free() replacements, those replacements may not be able to free allocated memory from the dll. 6. Some global static variables are properly initialised. Just personal preference and habit while scanning through source code. The changes are optional. 7. Some minor formatting changes: tab -> spaces. The changes are also optional.
Hope this help. Back to the warning fixes:1. The warning for raw_connect() is actually a warning for the call to htons() which needs to trim argument port to u_short. It is nothing to do with raw_connect which just expands the u_short returned from htons() to unsigned int, that's perfectly fine. Anyway, the proper fix is actually to define port as u_short or uint16_t from the very beginning. 2. For setsockopt(), changing flag to const int won't help. The problem is that int* and char* are not compatible in anyway. Just checked the argument is defined as const void * for freebsd and linux (vs const char * on windows). So I believe, to make all kinds of c compilers happy, the cast should be const void * instead, like:
- setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof flag);+ setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (const void *)&flag, sizeof flag); This should be perfectly fine, sort of just explicitly expressing what the compiler will do. 3. As SOCKET is defined as unsigned int (u_int) on windows, supposingly portable socket code (simply using int as socket handle) usually ends up warnings on windows where socket apis are prototyped using SOCKET instead of int. One proper way to fix the warnings without using a lot of explicit castings is to define SOCKET as int and use SOCKET instead for unix platforms. I thought about to make the change to ne_socket.c but then the change would be fairly large and I wonder if you would accept such a change. The change would also make the code looks less familiar to native unix developers. If you think this is a good idea to make the code more generic across windows and unix, I am more than willing to help. Btw, while I prefer compilation warning free, the new attached patches have a change to define SOCKET for non-windows platforms and hence I can make the cast works for all platforms.
Regards, Kiyo
Joe Orton wrote:
Hi Kiyo, thanks for sending in the patch. In the future, it's easier if you submit separate patches (preferably in diff -u format) in separate mails for unrelated changes.On Fri, Aug 04, 2006 at 10:12:02PM +1000, Kiyo Kelvin Lee wrote:One minor problem in ne_sspi_clear_context() (ne_sspi.c) which does not return properly.I've applied this.Another strange problem (also in ne_sspi.c) is that the mssdk comes with vc6 does not define FreeCredentialsHandle but define FreeCredentialHandle instead. (note that changed from singular to plural)I've applied this too.BTW, attached is a patch to make neon cleanly (no warning) compile with vc6, vs2003 and vs2005.Need to roll back the change to neon.mak if still using vc6 though.Is there no way to make neon.mak work with all the different vintages of compiler suite? I've also not applied the following changes:--- src/ne_socket.c (revision 1053) +++ src/ne_socket.c (working copy) @@ -449,7 +449,7 @@ /* Init the fd set */ FD_ZERO(&rdfds); do { - FD_SET(fdno, &rdfds); + FD_SET((SOCKET)fdno, &rdfds); if (tvp) { tvp->tv_sec = secs; tvp->tv_usec = 0; this is not portable; SOCKET is Win32-specific. @@ -1012,11 +1012,11 @@ { /* Disable the Nagle algorithm; better to add write buffering * instead of doing this. */ int flag = 1; - setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof flag); + setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (const char*)&flag, sizeof flag); }is this just for a warning fix? Does changing "int flag" to "const int flag" have the same effect?#endif - if (raw_connect(fd, addr, htons(port))) { + if (raw_connect(fd, addr, htons((u_short)port))) { set_strerror(sock, ne_errno); ne_close(fd); return -1;Again, is this just to fix a warning? htons() should return a 16-bit unsigned int of some kind, which should be fine to pass to raw_connect().Regards, joe
neon-0.26.1-p1-patches.tbz
Description: Binary data
_______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
