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
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@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 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@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@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@gmail.com writes:
Jesse> On Wed, 2 Mar 2005 11:51:57 -0700, Jesse Allen Jesse> the3dfxdude@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...
On Wed, 2 Mar 2005 20:24:27 +0100, Uwe Bonnes bon@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@gmail.com wrote:
On Wed, 2 Mar 2005 20:24:27 +0100, Uwe Bonnes bon@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 ) ) {
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.genera....
Please don't hesitate to contact us with any other questions or concerns. Thanks for your interest in Google. ---------------------------
bye Fabi
-
Andreas Mohr -
Fabian Cenedese -
Jesse Allen -
Krzysztof Foltman -
Mike McCormack -
Uwe Bonnes