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
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
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
- Fixed a bug in misc/win32/misc.c that caused WinNT 3.x to always be
detected as APR_WIN_UNSUP.
- Updated misc/win32/misc.c and include/arch/win32/apr_arch_misc.h
with the defines and detection code for Win2000 SP3 and SP4, and WinXP
SP1 and SP2.
Patch is against the current HEAD (rev 123376)
In reply to my earlier question - went ahead and did it.
What this patch does is fix all conditionals that depend implicitely
on APR_SUCCESS being zero to perform an explicit test against its
*macro definition* and not against the numeric literal or the C
expression evaluation.
No call or return
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 places around the APR codebase that do stuff like this:
if (rv)
return rv;
I based my question on the fact that the majority of the cases seem to
explicitely check against the macro.
Oh well, should've waited before patching. It was a nice way of
getting the overall feel of the library though - nice work!
On Mon, 27 Dec 2004 09:44:06 -0500, Garrett Rooney
[EMAIL
On Mon, 27 Dec 2004, Garrett Rooney wrote:
This seems to defeat the point of having an APR_SUCCESS in the first
place. It's also (at least in my eyes) slightly less intuitive than
explicit testing.
Part of the definition of apr_status_t is the fact that APR_SUCCESS is
defined to be zero.
Cliff Woolley wrote:
But because it is defined to be zero,
if (rv != APR_SUCCESS) {
return rv;
}
will be equivalent to and just as fast as
if (!rv) {
return rv;
}
on any remotely reasonable compiler.
Ok, I think we may be talking about two different cases...
There's
Check, I hear you. I'll split it tomorrow then (tired right now and
working while tired is a no-no) and resubmit the
positive-success-report version.
On Mon, 27 Dec 2004 12:35:06 -0500, Garrett Rooney
[EMAIL PROTECTED] wrote:
Ok, I think we may be talking about two different cases...
On Mon, 27 Dec 2004, Garrett Rooney wrote:
Ok, I think we may be talking about two different cases...
There's the check if a call returned an error, and if so return that to
your caller case, which personally I think is easist to read as:
if (rv)
return rv;
No, that's just me mixing up
On Mon, 27 Dec 2004, Mihai Limbasan wrote:
In reply to my earlier question - went ahead and did it.
What this patch does is fix all conditionals that depend implicitely
on APR_SUCCESS being zero to perform an explicit test against its
*macro definition* and not against the numeric literal or
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
At 12:43 PM 12/27/2004, Mihai Limbasan wrote:
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).
The file_io/unix/fullrw.c is
14 matches
Mail list logo
