%Fp printf format specifier
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. 06151 162516 -------- Fax. 06151 164321 ----------
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
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
%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
"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. 06151 162516 -------- Fax. 06151 164321 ----------
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
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
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
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.
"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. 06151 162516 -------- Fax. 06151 164321 ----------
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; }
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 ) ) {
participants (5)
-
Andreas Mohr -
Jesse Allen -
Krzysztof Foltman -
Mike McCormack -
Uwe Bonnes