apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <li...@rowe-clan.net>
Subject Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
Date Mon, 14 May 2001 00:49:32 GMT
From: "Jeff Trawick" <trawickj@bellsouth.net>
Sent: Sunday, May 13, 2001 7:15 PM


> "William A. Rowe, Jr." <lists@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.


Mime
View raw message