apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [REPOST] printf and FMT values.
Date Tue, 01 May 2001 05:44:41 GMT
On Mon, Apr 30, 2001 at 10:03:02PM -0400, Jeff Trawick wrote:
> rbb@covalent.net writes:
> 
> > There is no need for apr_*printf formats to be compatible with OS printf
> > calls.  We have re-implemented apr_*printf because we needed better
> > portability.  In reality, that means that we could easily just define a
> > single set of format strings.
> 
> Let's keep in mind that we get two huge benefits from apr_*printf()
> formats matching OS printf calls:
> 
> 1) trivial learning curve
> 2) !!!!!gcc (and certain other compiler) warnings keep us straight!!!!!
> 
> The ability to use printf() is not bad either, though of course we
> could APR-ize further.

Well, the only glaring omission to apr_*printf() is support for "%lld" -
which is how Solaris prints long longs.   I agree with you - I think 
they should be identical to OS printf calls - it does make things so
much simpler and obvious to the uninformed (like me).  However, this 
does require apr_*printf() to support all format strings that are legal
in any OS supported by APR.  But, that's a fair tradeoff, I think.
And, I think it borders on lunacy to require the user to give up
printf() to print to stdout when there is no viable, clean alternative 
in APR (must explictly open stdout with apr_file_open_stdout and then
call apr_file_printf(), then don't forget to close stdout when you
are done).

The trivial patch to apr_snprintf.c is attached to add "%lld" support.
If anyone wants to commit it, please feel free to do so.  There are 
also some cleanups in configure.in that should probably be changed to 
go from "%qd" to "%lld" so that they work under Solaris's printf().

When I submitted my apr_int64_t patches, I used "%lld" for 
APR_INT64_T_FMT (I only thought it had to work with printf).  So, if 
anyone tries to actually use that in Unix with apr_*printf() - it won't 
work.  Not sure if there are any references in the code to that #define
since it is so recent.

In fact, I think you could even remove "%qd" as a format string unless 
we find a native OS printf call that does not support "%lld" - all three 
OSes I regularly use (Linux, FreeBSD, and Solaris) support "%lld" - my 
guess is that only older OSes might only have "%qd" support.  Is anyone
aware of any specific OSes that use only "%qd" - note that the FreeBSD
man pages indicate only "%qd", but the FreeBSD 4.2 (at least) support
"%lld" (see the source code for libc - I've posted the full reference
earlier).  -- justin

Index: strings/apr_snprintf.c
===================================================================
RCS file: /home/cvspublic/apr/strings/apr_snprintf.c,v
retrieving revision 1.14
diff -u -r1.14 apr_snprintf.c
--- strings/apr_snprintf.c	2001/04/27 18:36:06	1.14
+++ strings/apr_snprintf.c	2001/04/28 05:44:18
@@ -814,6 +814,11 @@
 	    else if (*fmt == 'l') {
 		var_type = IS_LONG;
 		fmt++;
+        if (*fmt == 'l')
+        {
+            var_type = IS_QUAD;
+		    fmt++;
+        }
 	    }
 	    else if (*fmt == 'h') {
 		var_type = IS_SHORT;


Mime
View raw message