You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2001/05/14 05:24:54 UTC
[lists@rowe-clan.net: Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c]
----- Forwarded message from "William A. Rowe, Jr." <li...@rowe-clan.net> -----
From: "William A. Rowe, Jr." <li...@rowe-clan.net>
Subject: Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
To: "Greg Stein" <gs...@lyra.org>
Date: Sun, 13 May 2001 21:09:40 -0500
Reply-To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
From: "Greg Stein" <gs...@lyra.org>
Sent: Sunday, May 13, 2001 8:56 PM
> > No. It's always a 32 bit int ...
>
> Um... what the hell are you talking about? :-)
>
> from apr_errno.h:
>
> typedef int apr_status_t;
duh, you are quite correct sir... I trusted my [failing] memory. Wonder if
neuroscience will come up with ECC regeneration some day :-)
> IOW, it is an "int". Who cares how many bits are in it?
Correct, there is no requirement for APR_STATUS_T_FMT.
> Jeff's change was just right. The only thing that will make it "not right"
> is if you go and muck with apr_status_t. However, that would be silly... we
> want a "natural" int, rather than forcing it to some specific size.
Of course, my bad, and nobody is suggesting _changing_ apr_status_t, no sir!
> > And at least BEOS won't
> > accept %d for a 32bit int representation.
>
> Huh? BeOS would be totally hosed if "%d" did not match "int".
I misread one of David's commits. Now I'm reading this right...
trawick 01/05/13 08:34:18
Modified: test test_apr.h testmd5.c testproc.c
Log:
fix some bad parms to printf/fprintf
- printf("Error was %ld : %s\n", rv, strerror(rv)); \
+ printf("Error was %d : %s\n", rv, strerror(rv)); \
This patch was goodness, and dunno what I was reading that suggested someone
actually needed %ld. Certainly %ld will bomb on some systems, and slip quietly
past on others. Thanks for catching these, Jeff!
> > > I wouldn't mind seeing APR_STATUS_T_FMT though... Why should the user
> > > stop to wonder which APR types are always the same and which are not?
> >
> > Yes, consistency is key.
>
> APR_STATUS_T_FMT has some merit. But it isn't required by any means. And if
> we do use it, then a simple "%d" is correct.
If someone wants to do this, great. I'm not about to spend the effort, given
that it's predictable :-)
----- End forwarded message -----
--
Greg Stein, http://www.lyra.org/
Re: [lists@rowe-clan.net: Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c]
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> From: "William A. Rowe, Jr." <li...@rowe-clan.net>
> Subject: Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
> To: "Greg Stein" <gs...@lyra.org>
> Date: Sun, 13 May 2001 21:09:40 -0500
> Reply-To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
>
>
> From: "Greg Stein" <gs...@lyra.org>
> Sent: Sunday, May 13, 2001 8:56 PM
>
>
> > > No. It's always a 32 bit int ...
> >
> > Um... what the hell are you talking about? :-)
> >
> > from apr_errno.h:
> >
> > typedef int apr_status_t;
>
> duh, you are quite correct sir... I trusted my [failing] memory. Wonder if
> neuroscience will come up with ECC regeneration some day :-)
well, there was some humor in there... on the one hand it was silly
to respond 'cause it was obviously a temporary misfire; on the other
hand I wouldn't want you to go off figuring out what to do with
APR_STATUS_T_FMT only to find at the end that it was mostly for naught
:)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...