Re: [REPOST] printf and FMT values.

[Jeff Trawick <tr...@bellsouth.net>]

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.

-- 
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: [REPOST] printf and FMT values.

["William A. Rowe, Jr." <ad...@rowe-clan.net>]

----- Original Message ----- 
From: "Luke Kenneth Casson Leighton" <lk...@samba-tng.org>
To: "Justin Erenkrantz" <je...@ebuilt.com>
Cc: "Jeff Trawick" <tr...@bellsouth.net>; <de...@apr.apache.org>
Sent: Tuesday, May 08, 2001 11:22 AM
Subject: Re: [REPOST] printf and FMT values.


> > > > 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.
> 
> > Well, the only glaring omission to apr_*printf() is support for "%lld" -
> 
> the other one that you may wish to consider adding, at some point,
> is Unicode printfs.

How to make it platform independent?

Remeber byte ordering is a _significant_ problem across platforms.

Also consider there is an implicit conversion involved, it's not trivial,
and it isn't clean.

It is not trivial to keep clean crossplatform byte/word oriented code portable.
Believe me, I'm _very_ familiar with Win32 BSTRs and native types.  It's isn't
a joking manner when the user has to connect to an external 8-bit oriented
resource, sends non-mappable data at it, and expects to get back what they stow.

This is why I'm 'turning' apr in the direction of utf-8 mapping.  When we know
the author's intent (such as the ms kernel guys' winnt filesystem) we can try
exposing such unicode constructs in the 'internationalized' build.  

> Win32 has %S for 'hey, am i in UNICODE mode?  okay!  let's convert
> this string to char*, then!' and vice-versa when you compile _not_
> in Unicode-mode...

Completely bogus...

> otherwise, Win32 treats a %s as default-whatever-you-have-compiled-as
> [%s is Unicode when compiled as Unicode, char* when compiled as char*]

which is evil.  APR supports the 'good comprimize' approach.  We would never
presume a char isn't a char, since ANSI/POSIX both offer wchar to accomplish
this.  WinNT further presumes [for filenames today, all resources at some point]
that resource identifiers are unicode.  

Apache is forgiving, in the sense that it doesn't care what filesystem is under
the hood.  If the resource can be found, it can be authorized and served. 
Greg Stein has asked for some mechansim to distinguish and support local character 
set (8bit) naming, but nobody has offered up any reasonable comprimize to WinNT's 
flippent attitude to the bouncing around code pages.  On unix, a char value is a 
specific value and the file will always 'just open'.  On WinNT, this isn't the case.

I'm very loathe to associate any meanings between high-bit char-byte values and
some glyph.  If we must, later, we need to approach the entire apr library in a very
measured way.  Today, utf-8 filename mapping assures us we can 'see' any filename
on the user's volumes (unless they are on Win9x/ME ;->).  

But unicode mapping within printf?  Entirely non-portable.

Bill

Re: [REPOST] printf and FMT values.

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

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


> Well, the only glaring omission to apr_*printf() is support for "%lld" -

the other one that you may wish to consider adding, at some point,
is Unicode printfs.

Win32 has %S for 'hey, am i in UNICODE mode?  okay!  let's convert
this string to char*, then!' and vice-versa when you compile _not_
in Unicode-mode...

otherwise, Win32 treats a %s as default-whatever-you-have-compiled-as
[%s is Unicode when compiled as Unicode, char* when compiled as char*]

luke

Re: [REPOST] printf and FMT values.

[Justin Erenkrantz <je...@ebuilt.com>]

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;