%Fp printf format specifier

[Uwe Bonnes]

Hallo,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HT...
uses a "%Fp" format spezifier. Running with native msvcrt, this seems to be
the same as "%p". However builtin msvcrt stumbles about the "superfluous" 'F".

Does anybody know what the meaning of the "F" is? I didn't find anything on
the net. And b.t.w., how do I get Google to not ignore the '%' in a search
for "%Fp"? And mingw/malloc.h has the definitions of _USEDENTRY and
_FREEENTRY excahnged and misses more entries...

Bye
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Krzysztof Foltman]

Dnia 02-03-2005, śro o godzinie 17:34 +0100, Uwe Bonnes napisał(a):
> uses a "%Fp" format spezifier. Running with native msvcrt, this seems to be
> the same as "%p". However builtin msvcrt stumbles about the "superfluous" 'F".

%p = pointer
%Fp = far pointer? (as in segment:offset pointer in 16-bit Windows)

Krzysztof

[Andreas Mohr]

Hi,

On Wed, Mar 02, 2005 at 06:23:40PM +0100, Krzysztof Foltman wrote:
> Dnia 02-03-2005, ??ro o godzinie 17:34 +0100, Uwe Bonnes napisa??(a):
> > uses a "%Fp" format spezifier. Running with native msvcrt, this seems to be
> > the same as "%p". However builtin msvcrt stumbles about the "superfluous" 'F".
>
> %p = pointer
> %Fp = far pointer? (as in segment:offset pointer in 16-bit Windows)
> Oh, right, so there most likely IS a difference between %p and %Fp, since
> %p will get shown as 0x12345678, whereas %Fp probably gets rendered as
> something like 0x1234:0x5678.

To sum it up:
a) we DO need to handle the F modifier
b) it is probably used to format a FAR pointer (0x1234:0x5678)
c) it should NOT be confused in any way with the lower-case-only float type
   specifier

Andreas Mohr

[Krzysztof Foltman]

> > %p = pointer
> > %Fp = far pointer? (as in segment:offset pointer in 16-bit Windows)
> > Oh, right, so there most likely IS a difference between %p and %Fp, since
> > %p will get shown as 0x12345678, whereas %Fp probably gets rendered as
> > something like 0x1234:0x5678.

Nope. There are no far pointers in 32-bit Windows. It's a legacy thing.
Just like LPSTR is a "long" pointer to string - yet there is no such
thing as 'long' pointer anymore.
> a) we DO need to handle the F modifier

Sure.
> b) it is probably used to format a FAR pointer (0x1234:0x5678)

Nope. There's no difference between %Fp and %p anymore (not in win32),
just like there is no difference between, say, PWORD and LPWORD.
> c) it should NOT be confused in any way with the lower-case-only float type
>    specifier

Sure.

Krzysztof

[Uwe Bonnes]

> > > > > "Andreas" == Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:

Andreas> Hi, On Wed, Mar 02, 2005 at 06:23:40PM +0100, Krzysztof Foltman
    Andreas> wrote:
    >> Dnia 02-03-2005, ??ro o godzinie 17:34 +0100, Uwe Bonnes napisa??(a):
    >> > uses a "%Fp" format spezifier. Running with native msvcrt, this
    >> seems to be > the same as "%p". However builtin msvcrt stumbles about
    >> the "superfluous" 'F".
    >> 
    >> %p = pointer %Fp = far pointer? (as in segment:offset pointer in
    >> 16-bit Windows)
    Andreas> Oh, right, so there most likely IS a difference between %p and
    Andreas> %Fp, since %p will get shown as 0x12345678, whereas %Fp
    Andreas> probably gets rendered as something like 0x1234:0x5678.

    Andreas> To sum it up: a) we DO need to handle the F modifier b) it is
    Andreas> probably used to format a FAR pointer (0x1234:0x5678) c) it
    Andreas> should NOT be confused in any way with the lower-case-only
    Andreas> float type specifier

With native MSVCRT there is no difference between %Fp and %p.  You can see
with the output on the MS web page about _heapwalk. And you can try
quite easily in our test suite. Maybe a 16 bit msvcrt might give different
results. 

I think the best solution is to ignore it for now, justified by a test case.

Bye
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Mike McCormack]

Uwe Bonnes wrote:
> With native MSVCRT there is no difference between %Fp and %p.  You can see
> with the output on the MS web page about _heapwalk. And you can try
> quite easily in our test suite. Maybe a 16 bit msvcrt might give different
> results.

I've been away for a few days of sun in Bali :)  I'll have a go at 
adding this to the regression tests and trying to fix the problem.  One 
problem is that the search for format characters should not be case 
insensitive.

Mike

[Andreas Mohr]

Hi,

On Wed, Mar 02, 2005 at 05:34:23PM +0100, Uwe Bonnes wrote:
> Hallo,
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HT...
> uses a "%Fp" format spezifier. Running with native msvcrt, this seems to be
> the same as "%p". However builtin msvcrt stumbles about the "superfluous" 'F".
>
> Does anybody know what the meaning of the "F" is? I didn't find anything on
> the net. And b.t.w., how do I get Google to not ignore the '%' in a search
> for "%Fp"? And mingw/malloc.h has the definitions of _USEDENTRY and
> _FREEENTRY excahnged and misses more entries...
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/...
> doesn't tell *anything*.

http://poli.cs.vsb.cz/c/help/alloc0.htm
has a "note the F modifier", which might hint that it is being used to indicate
a "far" pointer...

http://66.102.9.104/search?q=cache:_wVnYKwdJh0J:icon.dyu.ac.kr/clib/farheapw...
strongly suggests the same...

And
http://poli.cs.vsb.cz/c/help/alloc0.htm
as well, except that it even uses "Fs"!

Do we even have to do anything on "F"?
"far" is long gone, right? As such simply silently ignore "F", right?

Andreas Mohr

[Jesse Allen]

On Wed, 2 Mar 2005 19:24:33 +0100, Andreas Mohr
<andi(a)rhlx01.fht-esslingen.de> wrote:
> Do we even have to do anything on "F"?
> "far" is long gone, right? As such simply silently ignore "F", right?

Right now in current CVS, our *printf will handle any strings.  For
any type numbers (except %n), they are forwarded to libc's printf by
first checking the format string for valid specifiers, and rebuilding
it for libc.
> From line 585 in dlls/msvcrt/wcs.c:
>         else if( pf_is_valid_format( flags.Format ) )
>         {
>             char fmt[20], number[40], *x = number;

if( flags.FieldLength >= sizeof number )
                x = HeapAlloc( GetProcessHeap(), 0, flags.FieldLength+1 );

            pf_rebuild_format_string( fmt, &flags );

            if( pf_is_double_format( flags.Format ) )
                sprintf( number, fmt, va_arg(valist, double) );

Both pf_is_valid_format and pf_is_double_format will accept 'F'  
(tolowerred...) modifiers, and libc will parse it.  Based on windows
behavior, it probably should be ignored?

Jesse

[Jesse Allen]

On Wed, 2 Mar 2005 11:51:57 -0700, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
> Right now in current CVS, our *printf will handle any strings.  For
> any type numbers (except %n), they are forwarded to libc's printf by

Oops, we handle %p differently too:
        /* output a pointer */
        else if( flags.Format == 'p' )
        {
            char pointer[10];

            flags.PadZero = 0;
            if( flags.Alternate )
                sprintf(pointer, "0X%08lX", va_arg(valist, long));
            else
                sprintf(pointer, "%08lX", va_arg(valist, long));
            r = pf_output_format_A( out, pointer, -1, &flags );
        }

I don't think it will allow an 'F' to get stuck in an sprintf call. 
If it did, then yeah, calling out libc's sprintf would mess it up.  Do
we have a test case for %Fp?  Uwe, what version of wine do you got?  I
think only an older version would pass it on.

[Uwe Bonnes]

> > > > > "Jesse" == Jesse Allen <the3dfxdude(a)gmail.com> writes:

Jesse> On Wed, 2 Mar 2005 11:51:57 -0700, Jesse Allen
    Jesse> <the3dfxdude(a)gmail.com> wrote:
    >> Right now in current CVS, our *printf will handle any strings.  For
    >> any type numbers (except %n), they are forwarded to libc's printf by


    Jesse> Oops, we handle %p differently too: /* output a pointer */ else
    Jesse> if( flags.Format == 'p' ) { char pointer[10];

    Jesse>             flags.PadZero = 0; if( flags.Alternate )
    Jesse> sprintf(pointer, "0X%08lX", va_arg(valist, long)); else
    Jesse> sprintf(pointer, "%08lX", va_arg(valist, long)); r =
    Jesse> pf_output_format_A( out, pointer, -1, &flags ); }

    Jesse> I don't think it will allow an 'F' to get stuck in an sprintf
    Jesse> call.  If it did, then yeah, calling out libc's sprintf would
    Jesse> mess it up.  Do we have a test case for %Fp?  Uwe, what version
    Jesse> of wine do you got?  I think only an older version would pass it
    Jesse> on.

Most recent CVS...
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Jesse Allen]

On Wed, 2 Mar 2005 20:24:27 +0100, Uwe Bonnes
<bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote:
> Most recent CVS...

Oh, since it hits 'F' first, it will try to parse it as 'f'.  Maybe
try this to see if it no longer accepts it as a valid specifer, and
then maybe it will parse it as a pointer.

--- wcs.c-original      2005-02-14 16:14:01.000000000 -0700
+++ wcs.c       2005-03-02 12:33:12.000000000 -0700
@@ -353,6 +353,8 @@
     char float_fmts[] = "acdefginoux";
     if (!fmt)
         return FALSE;
+    if (fmt == 'F')
+        return FALSE;
     fmt = tolower( fmt );
     return strchr( float_fmts, fmt ) ? TRUE : FALSE;
 }

[Jesse Allen]

On Wed, 2 Mar 2005 12:35:47 -0700, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
> On Wed, 2 Mar 2005 20:24:27 +0100, Uwe Bonnes
> <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote:
> > Most recent CVS...
>
> Oh, since it hits 'F' first, it will try to parse it as 'f'.  Maybe
> try this to see if it no longer accepts it as a valid specifer, and
> then maybe it will parse it as a pointer.

This one is better because the other one will stop the parsing:

--- wcs.c-original      2005-02-14 16:14:01.000000000 -0700
+++ wcs.c       2005-03-02 12:51:05.000000000 -0700
@@ -555,6 +555,12 @@
             *x = out->used;
         }
 
+        /* %F is silently ignored */
+        else if( flags.Format == 'F' )
+        {
+
+        }
+
         /* deal with integers and floats using libc's printf */
         else if( pf_is_valid_format( flags.Format ) )
         {

[Fabian Cenedese]

> the net. And b.t.w., how do I get Google to not ignore the '%' in a search
> for "%Fp"?

You're out of luck (presently). I also had this problem and asked them
about it. Here's their answer:

---------------------------
Thank you for your note. Google currently does not recognize search terms
containing exclamation points, question marks, the @ sign, and other such
characters. These characters are so common that including them in a search
would greatly slow down results delivery and hurt search performance.
Furthermore, the use of punctuation on the Web is so inconsistent (for
example, there's no obvious way to decide between Mr. and Mr) that
including it in the query often does more harm than good.

That said, we know that many useful search terms do contain such
characters. We've generated exceptions for terms like C++ and are studying
ways to enable search terms like F# and C/net. We'll keep your feedback in
mind as we work to improve the quality of our search.

For more information, please visit
http://www.google.com/help/refinesearch.html . Other helpful information
can be found at http://groups.google.com in the
http://groups.google.com/groups?hl=en&group=google.public.support.generalgro....

Please don't hesitate to contact us with any other questions or concerns.
Thanks for your interest in Google.
---------------------------


bye  Fabi