You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <li...@rowe-clan.net> on 2001/05/13 19:21:27 UTC

Re: 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
>   
>   -            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 (?).


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...