[PATCH] [REPOST] Fix some VC++ 2003 level 3 warnings

2004-12-27 Thread Mihai Limbasan
Forgot to attach the patch. Thanks, Garret :) > Minor patch that fixes a few warnings coming up with the (APR default) > warning level 3 when building on VC++ 2003, IA32. > Patch is against the current HEAD (rev 123376). -- Mihai Limbasan vc-fix-warnlvl3.diff Description: Binary data

[PATCH] Remove superfluous apr_get_os_error() in Win32 apr_thread_cond_timedwait()

2004-12-27 Thread Mihai Limbasan
The apr_get_os_error() call right after the second WAIT_OBJECT_0 test is unnecessary (1 extra call + 1 extra temporary on stack, value never used). There's a catchall return apr_get_os_error() lines below. Attached patch against HEAD to remove it. -- Mihai Limbasan win32-superf

Re: apr_status_t testing against APR_SUCCESS usage question

2004-12-27 Thread Mihai Limbasan
tch seems to deal with both situations, and in the first case I > just don't see how it helps other than making things more verbose when > there's little need. > > -garrett > -- Mihai Limbasan

Re: apr_status_t testing against APR_SUCCESS usage question

2004-12-27 Thread Mihai Limbasan
t;[EMAIL PROTECTED]> wrote: > Mihai Limbasan wrote: > >>From what I've gathered reviewing the APR code, the canonical way of > > testing apr_* return values is comparing against APR_SUCCESS. That > > happens to be #defined as zero. > > > > There are a lot of pl

[PATCH] Fix assumptions about value of APR_SUCCESS being zero

2004-12-27 Thread Mihai Limbasan
future maintainability. I think I caught all the instances that did implicit checks. Patch is against the current HEAD (rev 123376). -- Mihai Limbasan no-assume-zero-apr_success.diff Description: Binary data

[PATCH] Win32 oslevel fix and update

2004-12-27 Thread Mihai Limbasan
) but should apply cleanly on any revision >=1.0.1. -- Mihai Limbasan win32-oslevels.diff Description: Binary data

apr_status_t testing against APR_SUCCESS usage question

2004-12-27 Thread Mihai Limbasan
>From what I've gathered reviewing the APR code, the canonical way of testing apr_* return values is comparing against APR_SUCCESS. That happens to be #defined as zero. There are a lot of places around the APR codebase that do stuff like this: if (rv) return rv; i.e. taking advantage

[PATCH] Fix some VC++ 2003 level 3 warnings

2004-12-27 Thread Mihai Limbasan
Minor patch that fixes a few warnings coming up with the (APR default) warning level 3 when building on VC++ 2003, IA32. Patch is against the current HEAD (rev 123376). -- Mihai

[PATCH] Trivial patch fixing up a few errorcodes.c strings

2004-12-27 Thread Mihai Limbasan
Attached is a minor patch fixing some error strings in misc/unix/errorcodes.c (missing periods, inconsistent language usage). Patch is against the current HEAD (rev 123376) but it should apply cleanly to pretty much any revision. Oh, and thanks for a great library - and a happy new year to all of y

Re: [BUG] Improper retval check on Win32 setsockopt() in sockopt.c

2004-12-25 Thread Mihai Limbasan
Ah, my bad, didn't notice -1 == SOCKET_ERROR. Still, it might be a good idea to replace the == -1 with an == SOCKET_ERROR, if only to avoid annoying people like me mailing :) Also, it's the canonical way. On Sat, 25 Dec 2004 23:32:13 +0200, Mihai Limbasan <[EMAIL PROT

[BUG] Improper retval check on Win32 setsockopt() in sockopt.c

2004-12-25 Thread Mihai Limbasan
apr_socket_opt_set() in network_io/win32/sockopt.c invokes setsockopt() a few times, a la if (setsockopt(sock->socketdes, SOL_SOCKET, SO_KEEPALIVE, (void *)&one, sizeof(int)) == -1) { return apr_get_netos_error(); } While that works just fine on Unix (retval -1 indicates error and requires su