apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject [lists@rowe-clan.net: Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c]
Date Mon, 14 May 2001 03:24:54 GMT
----- Forwarded message from "William A. Rowe, Jr." <lists@rowe-clan.net> -----

From: "William A. Rowe, Jr." <lists@rowe-clan.net>
Subject: Re: cvs commit: apr/test test_apr.h testmd5.c testproc.c
To: "Greg Stein" <gstein@lyra.org>
Date: Sun, 13 May 2001 21:09:40 -0500
Reply-To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>

From: "Greg Stein" <gstein@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
  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/

View raw message