_stprintf
in [MFC]
|
From: Joseph M. Newcomer on 8 Aug 2006 00:17 You should. I have it. It's in the platform SDK. All I did was single-step into it to get the source code, which Microsoft distributes. if you don't have it, you should be able to get it. You seem to be confused about performing an experiment. The formal specification of the %c formatting code is part of the ANSI/ISO standard and is unlikely to change. %lc and %C are Microsoft extensions, so there is every reason to expect that %c is going to conform to the formal language specification; until such time as the ISO committee sees fit to redefine this behavior (which would break millions of lines of existing code, so it is unlikely) we can expect it will continue to work according to the standard. joe On Tue, 8 Aug 2006 12:46:21 +0900, "Norman Diamond" <ndiamond(a)community.nospam> wrote: >"READING THE CODE" > >I don't have the source code to StringCchPrintf. (Source code to some of >Microsoft's versions of ISO printf and stuff like that yes, this one no.) > >"PERFORMING THE EXPERIMENT" > >And getting a result which works today in one version of Windows XP with one >version of MS Office and one version of Internet Explorer and four versions >of Visual Studio to muddy the waters. It won't work tomorrow. For some of >the incorrect statements in MSDN this kind of experiment is useful in >proving them incorrect, but it's not a reliable way to make reliable code >myself. > >"Now, if you have a working system with code page 932 in place," > >give or take an order of magnitude (in the quantity of such systems)... > > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:5thdd297fn5d56bd53jnfl78pql63nu1gm(a)4ax.com... >>I think the confusion here is that you are interpreting "character" in one >>context as "a >> sequence of bytes representing a glyph", and StringCchPrintf, as I said, >> when %c is used, >> does NOT interpret the word 'character' this way. So you can interpret it >> any way you >> want, but the only interpretation that matters is the interpretation given >> by >> StringCchPrintf, and you can see that easily, as I said, by READING THE >> CODE and >> PERFORMING THE EXPERIMENT. Now, if you have a working system with code >> page 932 in place, >> try the experiments I did, and tell us what you get. Try %c, in an ANSI >> code page, using >> any bit value of your choice for the character value, and tell us what >> StringCchPrintf >> does with respect to %c. I was not discussing %s, but %c, which you >> insist won't work. So >> if you're convinced it produces more than one 8-bit character or 16-bit >> character of >> output, please demonstrate this. Note that %lc and %C *do* expand wide >> character codes to >> multibyte representations, but that was not what we were discussing. >> joe >> >> On Thu, 3 Aug 2006 10:34:15 +0900, "Norman Diamond" >> <ndiamond(a)community.nospam> wrote: >> >>>> Multibyte Character Set is an *encoding* of a character set. >>> >>>Yes, ANSI code page 932 is an encoding just like other ANSI code pages >>>such >>>as (I might not be remembering these numbers correctly) 1252 and 850. >>> >>>> however, StringCchPrintf, sprintf, etc. do only convert characters using >>>> code pages in special cases, e.g., %lc or %C format. >>> >>>And %s and stuff like that. (If you're compiling in an ANSI environment >>>then simply use %s, but if you're compiling in a Unicode environment and >>>want to produce an ANSI encoded string then use %S.) >>> >>>> For ANSI mode, this means that 'character' is 'byte'. In ANSI mode, one >>>> character is one byte. >>> >>>For some reason I thought that you had sometimes written code targetting >>>ANSI code pages in which you knew that these statements are not true. It >>>looks like I misremembered. OK, then it seems that this is your >>>introduction to such code pages. In ANSI mode, one character is one or >>>more >>>bytes. In the ANSI code pages that Microsoft implemented, one character >>>is >>>one or two bytes, no more than two. >>> >>>I haven't been using Japanese Microsoft systems for nearly 20 years, I've >>>only been using them for half that length of time and occasionally seen >>>them >>>in use the other half of that time while I was using Japanese Unix and >>>Japanese VMS systems. I've used %s format in printf in Japanese Unix and >>>VMS and Windows systems. This is one kind of experiment that you don't >>>need >>>to tell me to do. >>> >>>I will continue to respect your expertise on matters other than character >>>encodings. >>> >>> >>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >>>news:b9i1d2p7ca3n59258h63bc1mavfgjngicd(a)4ax.com... >>>> Multibyte Character Set is an *encoding* of a character set. In ANSI >>>> mode, MBCS can be >>>> used to encode 'characters' in an extended set; however, >>>> StringCchPrintf, >>>> sprintf, etc. do >>>> only convert characters using code pages in special cases, e.g., %lc or >>>> %C >>>> format. The >>>> formal definition for %c, the formatting code being discussed in this >>>> example, is that >>>> the int argument is converted to 'unsigned char' and formatted as a >>>> character. For ANSI >>>> mode, this means that 'character' is 'byte'. In ANSI mode, one >>>> character >>>> is one byte. >>>> >>>> In a multibyte character set, a glyph might be represented by one to >>>> four >>>> successive 8-bit >>>> bytes. Note that using %c would be erroneous for formatting an integer >>>> value, if the >>>> intent was to produce a multibyte sequence representing a single logical >>>> character. >>>> >>>> This can easily be seen by looking at the %c formatting code in output.c >>>> in the CRT >>>> source. %c formats exactly one byte in ANSI mode. So arguing that %c >>>> requires two bytes >>>> for a character is not correct. >>>> >>>> The exact code executed for %c formatting is >>>> unsigned short temp; >>>> temp = (unsigned short) get_int_arg(&argptr); >>>> { >>>> buffer.sz[0] = (char) temp; >>>> textlen = 1; >>>> } >>>> >>>> I see nothing here that can generate more than one byte of output. Note >>>> that the %C and >>>> %lc formats, which take wide character values and format them in >>>> accordance with the code >>>> page, *can* generate more than o
From: David Ching on 8 Aug 2006 00:41 "Norman Diamond" <ndiamond(a)community.nospam> wrote in message news:%23RJd%230puGHA.3912(a)TK2MSFTNGP03.phx.gbl... > > I don't have the source code to StringCchPrintf. (Source code to some of > Microsoft's versions of ISO printf and stuff like that yes, this one no.) > I haven't followed this thread very carefully, but the source for StringCchPrintf is in strsafe.h (the file that declares this function also has the source, used for the inline version). -- David
From: Norman Diamond on 8 Aug 2006 01:54 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:8CUBg.2602$o27.739(a)newssvr21.news.prodigy.com... > "Norman Diamond" <ndiamond(a)community.nospam> wrote in message > news:%23RJd%230puGHA.3912(a)TK2MSFTNGP03.phx.gbl... >> >> I don't have the source code to StringCchPrintf. (Source code to some of >> Microsoft's versions of ISO printf and stuff like that yes, this one no.) > > I haven't followed this thread very carefully, but the source for > StringCchPrintf is in strsafe.h (the file that declares this function also > has the source, used for the inline version). You're right, thank you, but... Yes I found the source code there and I thank you. It is an inline function so indeed the source is there. But the source is rather shallow. Depending on the compilation environment it calls StringVPrintfWorkerA or StringVPrintfWorkerW. StringVPrintfWorkerA is the one relevant to this sub-thread. I still can't find the real source.
From: David Ching on 8 Aug 2006 10:42 "Norman Diamond" <ndiamond(a)community.nospam> wrote in message news:e4GIg8quGHA.3552(a)TK2MSFTNGP03.phx.gbl... > Yes I found the source code there and I thank you. It is an inline > function so indeed the source is there. But the source is rather shallow. > Depending on the compilation environment it calls StringVPrintfWorkerA or > StringVPrintfWorkerW. StringVPrintfWorkerA is the one relevant to this > sub-thread. I still can't find the real source. Hmm, SpringVPrintFWorkerA is also in strsafe.h (mine is dated February 2/26/2003). It calls _vsnprintf which is in vsprintf.c, and that calls _output, in output.c. Boy, Visual Assist from www.wholetomato.com really makes this stuff easy to find! :-) -- David
From: Joseph M. Newcomer on 8 Aug 2006 10:46
I did. It, not surprisingly, is in the same file! In my copies, it is on line 5578 in one of the platform SDK editions, and on line 5348 in the platform SDK that comes with VS.NET 2003. Have you not heard of Find In Files? Even a simple Find command would have worked! And single-stepping through the sourcewith the debugger is remarkably informative and should be attempted. Note that StringVPrintfWorkerA calls _vnsprintf, which is part of the C runtime, for which the source is also available! See vsprintf.c in the CRT source directory. This in turn calls _output, which, just to maintain the theme, ALSO has its complete source available, in output.c in the CRT source directory. joe On Tue, 8 Aug 2006 14:54:21 +0900, "Norman Diamond" <ndiamond(a)community.nospam> wrote: >"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message >news:8CUBg.2602$o27.739(a)newssvr21.news.prodigy.com... >> "Norman Diamond" <ndiamond(a)community.nospam> wrote in message >> news:%23RJd%230puGHA.3912(a)TK2MSFTNGP03.phx.gbl... >>> >>> I don't have the source code to StringCchPrintf. (Source code to some of >>> Microsoft's versions of ISO printf and stuff like that yes, this one no.) >> >> I haven't followed this thread very carefully, but the source for >> StringCchPrintf is in strsafe.h (the file that declares this function also >> has the source, used for the inline version). > >You're right, thank you, but... > >Yes I found the source code there and I thank you. It is an inline function >so indeed the source is there. But the source is rather shallow. Depending >on the compilation environment it calls StringVPrintfWorkerA or >StringVPrintfWorkerW. StringVPrintfWorkerA is the one relevant to this >sub-thread. I still can't find the real source. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |