You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by tr...@apache.org on 2001/05/13 17:34:18 UTC
cvs commit: apr/test test_apr.h testmd5.c testproc.c
trawick 01/05/13 08:34:18
Modified: test test_apr.h testmd5.c testproc.c
Log:
fix some bad parms to printf/fprintf
Revision Changes Path
1.3 +2 -2 apr/test/test_apr.h
Index: test_apr.h
===================================================================
RCS file: /home/cvs/apr/test/test_apr.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- test_apr.h 2001/05/13 14:40:57 1.2
+++ test_apr.h 2001/05/13 15:34:17 1.3
@@ -63,7 +63,7 @@
{ apr_status_t rv; \
if ((rv = func) == value){ \
printf("%s\n", bad); \
- printf("Error was %ld : %s\n", rv, strerror(rv)); \
+ printf("Error was %d : %s\n", rv, strerror(rv)); \
exit(-1); \
} \
printf("%s\n", good); \
@@ -74,7 +74,7 @@
{ apr_status_t rv; \
if ((rv = func) != value){ \
printf("%s\n", bad); \
- printf("Error was %ld : %s\n", rv, strerror(rv)); \
+ printf("Error was %d : %s\n", rv, strerror(rv)); \
exit(-1); \
} \
printf("%s\n", good); \
1.9 +1 -1 apr/test/testmd5.c
Index: testmd5.c
===================================================================
RCS file: /home/cvs/apr/test/testmd5.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- testmd5.c 2001/05/13 10:53:01 1.8
+++ testmd5.c 2001/05/13 15:34:17 1.9
@@ -106,7 +106,7 @@
if (xlate) {
#if APR_HAS_XLATE
if ((rv = apr_md5_set_xlate(&context, xlate)) != APR_SUCCESS){
- fprintf("Couldn't set the MD5 translation handle!\n");
+ fprintf(stderr, "Couldn't set the MD5 translation handle!\n");
exit(-1);
}
#else
1.28 +1 -1 apr/test/testproc.c
Index: testproc.c
===================================================================
RCS file: /home/cvs/apr/test/testproc.c,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- testproc.c 2001/05/13 10:42:08 1.27
+++ testproc.c 2001/05/13 15:34:17 1.28
@@ -140,7 +140,7 @@
if (!strcmp(buf, teststr))
printf("OK\n");
else {
- printf( "Uh-Oh\n", buf);
+ printf( "Uh-Oh\n");
printf(" (I actually got %s_\n", buf);
}
}
Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <li...@rowe-clan.net> writes:
> From: "Jeff Trawick" <tr...@bellsouth.net>
> Sent: Sunday, May 13, 2001 7:15 PM
>
>
> > "William A. Rowe, Jr." <li...@rowe-clan.net> writes:
> >
> > > > 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)); \
> > >
> > > Do I smell a need for an APR_STATUS_T_FMT ? It doesn't seem we can assume
> > > this on 64 bit machines (?).
> >
> > apr_status_t is always int so %d is always correct (though I suppose
> > the code in apr_errno.h could change).
>
> No. It's always a 32 bit int ... I want my fully 64 bit machine (none of this
> silly 32 bit numeric magic with 64 bit pointer cruft). And at least BEOS won't
> accept %d for a 32bit int representation.
Please look at the declaration in apr_errno.h. It is always int, and
%d is always correct for int. It is not apr_int32_t or apr_uint32_t
or anything like that. The right format string doesn't vary between
systems.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
Posted by Greg Stein <gs...@lyra.org>.
On Sun, May 13, 2001 at 07:49:32PM -0500, William A. Rowe, Jr. wrote:
> From: "Jeff Trawick" <tr...@bellsouth.net>
> Sent: Sunday, May 13, 2001 7:15 PM
>
> > "William A. Rowe, Jr." <li...@rowe-clan.net> writes:
> >
> > > > 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)); \
> > >
> > > Do I smell a need for an APR_STATUS_T_FMT ? It doesn't seem we can assume
> > > this on 64 bit machines (?).
> >
> > apr_status_t is always int so %d is always correct (though I suppose
> > the code in apr_errno.h could change).
>
> No. It's always a 32 bit int ... I want my fully 64 bit machine (none of this
Um... what the hell are you talking about? :-)
from apr_errno.h:
/**
* Type for specifying an error or status code.
*/
typedef int apr_status_t;
IOW, it is an "int". Who cares how many bits are in it?
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.
>...
> 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".
> As I mentioned in an aside to David, the first bit is an APR_INT32_T_FMT, which
> can be the simple basis for APR_STATUS_T_FMT on all platforms.
No. APR_STATUS_T_FMT would simply be "%d". Everywhere.
> > 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
Posted by "William A. Rowe, Jr." <li...@rowe-clan.net>.
From: "Jeff Trawick" <tr...@bellsouth.net>
Sent: Sunday, May 13, 2001 7:15 PM
> "William A. Rowe, Jr." <li...@rowe-clan.net> writes:
>
> > > 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)); \
> >
> > Do I smell a need for an APR_STATUS_T_FMT ? It doesn't seem we can assume
> > this on 64 bit machines (?).
>
> apr_status_t is always int so %d is always correct (though I suppose
> the code in apr_errno.h could change).
No. It's always a 32 bit int ... I want my fully 64 bit machine (none of this
silly 32 bit numeric magic with 64 bit pointer cruft). And at least BEOS won't
accept %d for a 32bit int representation.
As I mentioned in an aside to David, the first bit is an APR_INT32_T_FMT, which
can be the simple basis for APR_STATUS_T_FMT on all platforms.
> 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.
Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <li...@rowe-clan.net> writes:
> > 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)); \
>
> Do I smell a need for an APR_STATUS_T_FMT ? It doesn't seem we can assume
> this on 64 bit machines (?).
apr_status_t is always int so %d is always correct (though I suppose
the code in apr_errno.h could change).
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?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
Posted by "William A. Rowe, Jr." <li...@rowe-clan.net>.
> 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)); \
Do I smell a need for an APR_STATUS_T_FMT ? It doesn't seem we can assume
this on 64 bit machines (?).