_stprintf
in [MFC]
|
From: Norman Diamond on 8 Aug 2006 22:18 OK, thank you for pointing me to more of the source code. For some reason after seeing an external declaration in a .h file I didn't even imagine the possibility that the external definition would be contained later in the same .h file instead of in a .c or .cpp somewhere. You and Mr. Ching were right about StringCchPrintf, as far as I can tell. From the amount of source code I read (not enough but I don't have time to keep searching) and from comments in the source code, I come up with two rough estimates. (1) The code that you recommended to the original poster: > StringCchPrintf(_T("%c"), B, sizeof(B) / sizeof(TCHAR), (BYTE)('a' + i)); will work reliably as you said, using the present implementation. (2) The documentation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/strings/stringreference/stringfunctions/stringcchprintf.asp > The size, in characters, of the destination buffer is telling yet another lie. Unlike CreateFile, the internal implementation of StringCchPrintf does not perform manipulations to make MSDN accurate, it shows that MSDN is false. In StringCchPrintf the size is in TCHARs. "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:f68hd29b4jo1iujkojjl09c9hq2fs5st0u(a)4ax.com... >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
From: Joseph M. Newcomer on 8 Aug 2006 23:58 Some versions of Windows implement DBCS, apparently the Japanese version of Windows had this support, but it is not documented as far as I can tell. joe On Tue, 8 Aug 2006 12:57:43 +0900, "Norman Diamond" <ndiamond(a)community.nospam> wrote: >I think my reply got lost or maybe accidentally sent personally to Dr. >Newcomer, sorry. > >"Since you can't use any multibyte encoding in CreateFile," > >I am astounded to see that assertion. > >CreateFile has created Japanese filenames since Windows 95 and NT 3.1 >(though not in some foreign versions of those operating systems). > >OpenFile created Japanese filenames in Windows 3.1, MS-DOS, etc. (though not >in some foreign versions of those operating systems). > >On FAT12, FAT16, and NTFS. > > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:nnidd2dckt42edmn498eemd3idlg53cpjb(a)4ax.com... >> But the limit is MAX_PATH characters. THat's what we've been discussing. >> In Unicode >> mode, the limit is MAX_PATH characters, which would occupy 2*MAX_PATH >> bytes. That is, >> MAX_PATH TCHARs, and therefore their comment is completely CONSISTENT with >> the fact that a >> 'character' is a 'TCHAR'. Since you can't use any multibyte encoding in >> CreateFile, I >> don't see where there is any problem here. 'character', in nearly every >> context we've >> discussed, means 'TCHAR'. >> >> This also means that if you are using Unicode to represent Kanji, then you >> should be able >> to use MAX_PATH Kanji characters to name a file. >> joe >> >> On Thu, 3 Aug 2006 17:13:52 +0900, "Norman Diamond" >> <ndiamond(a)community.nospam> wrote: >> >>>"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message >>>news:Xns9813EB11E9700MihaiN(a)207.46.248.16... >>>>> The one for which Microsoft sent personal e-mail was CreateFile. >>>>> Microsoft assured me that even the ANSI version (CreateFileA) uses >>>>> Unicode internally and MAX_PATH is the limit on the number of >>>>> characters >>>>> internally, so if an ANSI application needs more than MAX_PATH bytes to >>>>> specify a usable filename then it can indeed do so. I've been a bit >>>>> negligent in not writing a test program to test this answer yet. >>>> >>>> But CreateFile does not take a number of chars as parameter. >>> >>>So what? Where we intuitively think that the stated limit of MAX_PATH >>>characters means MAX_PATH chars in ANSI, Microsoft informed me that the >>>limit really is MAX_PATH characters even if it takes twice that many >>>bytes. >>>You asked for examples of cases where we had been wrong in nearly always >>>assuming that MSDN's statements about characters meant TCHARs, and this is >>>a >>>big example. >>> >>>> What I suspect is happening is that the MAX_PATH is the limit if you >>>> don't >>>> use "\\?\" and is there both in the W and A versions. >>>> And since the A version does a conversion to Unicode and calls the W >>>> one, >>>> the limit is probably there and expressed in utf16 code units, indeed. >>> >>>You suspect that Microsoft's e-mail to me was accurate, and as mentioned, >>>I >>>have the same impression. Though they send a lot of unbelievable e-mails, >>>they send some believable e-mails too and this was one. >>> >>>> Interesting for some week-end experiments :-) >>> >>>Yup. By the way, considering that VFAT can store a filename consisting of >>>around 250 Kanji, one weekend experiment would be to try opening the file >>>under Windows 98 (Japanese version of course). But really I'll consider >>>it >>>close enough if it works under Windows 2000, XP, 2003, and Vista beta. I >>>haven't had time to test it and I do believe that mail. >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 9 Aug 2006 00:00 That's 'deprecated', not 'decremented'. If you include strsafe.h it redefines all the obsolete and unsafe methods to issue error messages. joe On Sat, 29 Jul 2006 19:04:01 -0700, Sonu <sonu(a)online.nospam> wrote: >Thanks guys, >I must be spacing out (as I seem to have been doing that often these days) >when I was using that %a instead of %c. >Definitely want to move to CString.... Though I'll have sit down and go >through my whole project and replave all this char stuff... >It's also giving the decremented error everywhere all over in VC2005, so now >I have a good excuse to use CString everywhere! > >Thanks a bunch as ususal... > >"David Webber" wrote: > >> >> "Vipin" <Vipin(a)nospam.com> wrote in message >> news:uxxt2Y1sGHA.4080(a)TK2MSFTNGP03.phx.gbl... >> >> > Good thing to use is this:- >> > CString str; >> > str.Format(_T("%c") , 'a' + j); >> >> Better is >> >> str.Format(_T("%c") , _T('a') + j ); >> >> Dave >> -- >> David Webber >> Author MOZART the music processor for Windows - >> http://www.mozart.co.uk >> For discussion/support see >> http://www.mozart.co.uk/mzusers/mailinglist.htm >> >> >> >> >> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 9 Aug 2006 00:00 That's 'deprecated', not 'decremented'. If you include strsafe.h it redefines all the obsolete and unsafe methods to issue error messages. joe On Sat, 29 Jul 2006 19:04:01 -0700, Sonu <sonu(a)online.nospam> wrote: >Thanks guys, >I must be spacing out (as I seem to have been doing that often these days) >when I was using that %a instead of %c. >Definitely want to move to CString.... Though I'll have sit down and go >through my whole project and replave all this char stuff... >It's also giving the decremented error everywhere all over in VC2005, so now >I have a good excuse to use CString everywhere! > >Thanks a bunch as ususal... > >"David Webber" wrote: > >> >> "Vipin" <Vipin(a)nospam.com> wrote in message >> news:uxxt2Y1sGHA.4080(a)TK2MSFTNGP03.phx.gbl... >> >> > Good thing to use is this:- >> > CString str; >> > str.Format(_T("%c") , 'a' + j); >> >> Better is >> >> str.Format(_T("%c") , _T('a') + j ); >> >> Dave >> -- >> David Webber >> Author MOZART the music processor for Windows - >> http://www.mozart.co.uk >> For discussion/support see >> http://www.mozart.co.uk/mzusers/mailinglist.htm >> >> >> >> >> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Norman Diamond on 9 Aug 2006 02:09
Here's the documentation for CreateFile: http://www.microsoft.com/japan/developer/library/jpwinpf/_win32_createfile.htm * Windows NT/2000$B!'$3$N4X?t$N(B ANSI $BHG$G$O!"L>A0$O:GBg(B MAX_PATH * $BJ8;z$K@)8B$5$l$F$$$^$9!#(B Essentially Microsoft's e-mail persuaded me to believe that part, and Mihai Nita believes it too. * Windows 95/98$B!'J8;zNs$ND9$5$O!":GBg(B MAX_PATH $BJ8;z$G$9!#(B Despite Microsoft's e-mail, both I and Mihai Nita think this looks doubtful. We think there's still a good chance that the limit in Windows 95/98 is MAX_PATH $B%P%$%H(B not $BJ8;z!#(B <snark> I don't blame Microsoft for not documenting Windows ME but I wonder why they don't document Windows 2003. </snark> Documentation of OpenFile seems to have been deleted: http://www.microsoft.com/japan/developer/library/jpwinpf/_win32_openfile.htm "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:n8nid21vbh9a1vre15md24ne6scjtvgomn(a)4ax.com... > Some versions of Windows implement DBCS, apparently the Japanese version > of Windows had > this support, but it is not documented as far as I can tell. > joe > > On Tue, 8 Aug 2006 12:57:43 +0900, "Norman Diamond" > <ndiamond(a)community.nospam> wrote: > >>I think my reply got lost or maybe accidentally sent personally to Dr. >>Newcomer, sorry. >> >>"Since you can't use any multibyte encoding in CreateFile," >> >>I am astounded to see that assertion. >> >>CreateFile has created Japanese filenames since Windows 95 and NT 3.1 >>(though not in some foreign versions of those operating systems). >> >>OpenFile created Japanese filenames in Windows 3.1, MS-DOS, etc. (though >>not >>in some foreign versions of those operating systems). >> >>On FAT12, FAT16, and NTFS. >> >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >>news:nnidd2dckt42edmn498eemd3idlg53cpjb(a)4ax.com... >>> But the limit is MAX_PATH characters. THat's what we've been >>> discussing. >>> In Unicode >>> mode, the limit is MAX_PATH characters, which would occupy 2*MAX_PATH >>> bytes. That is, >>> MAX_PATH TCHARs, and therefore their comment is completely CONSISTENT >>> with >>> the fact that a >>> 'character' is a 'TCHAR'. Since you can't use any multibyte encoding in >>> CreateFile, I >>> don't see where there is any problem here. 'character', in nearly every >>> context we've >>> discussed, means 'TCHAR'. >>> >>> This also means that if you are using Unicode to represent Kanji, then >>> you >>> should be able >>> to use MAX_PATH Kanji characters to name a file. >>> joe >>> >>> On Thu, 3 Aug 2006 17:13:52 +0900, "Norman Diamond" >>> <ndiamond(a)community.nospam> wrote: >>> >>>>"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message >>>>news:Xns9813EB11E9700MihaiN(a)207.46.248.16... >>>>>> The one for which Microsoft sent personal e-mail was CreateFile. >>>>>> Microsoft assured me that even the ANSI version (CreateFileA) uses >>>>>> Unicode internally and MAX_PATH is the limit on the number of >>>>>> characters >>>>>> internally, so if an ANSI application needs more than MAX_PATH bytes >>>>>> to >>>>>> specify a usable filename then it can indeed do so. I've been a bit >>>>>> negligent in not writing a test program to test this answer yet. >>>>> >>>>> But CreateFile does not take a number of chars as parameter. >>>> >>>>So what? Where we intuitively think that the stated limit of MAX_PATH >>>>characters means MAX_PATH chars in ANSI, Microsoft informed me that the >>>>limit really is MAX_PATH characters even if it takes twice that many >>>>bytes. >>>>You asked for examples of cases where we had been wrong in nearly always >>>>assuming that MSDN's statements about characters meant TCHARs, and this >>>>is >>>>a >>>>big example. >>>> >>>>> What I suspect is happening is that the MAX_PATH is the limit if you >>>>> don't >>>>> use "\\?\" and is there both in the W and A versions. >>>>> And since the A version does a conversion to Unicode and calls the W >>>>> one, >>>>> the limit is probably there and expressed in utf16 code units, indeed. >>>> >>>>You suspect that Microsoft's e-mail to me was accurate, and as >>>>mentioned, >>>>I >>>>have the same impression. Though they send a lot of unbelievable >>>>e-mails, >>>>they send some believable e-mails too and this was one. >>>> >>>>> Interesting for some week-end experiments :-) >>>> >>>>Yup. By the way, considering that VFAT can store a filename consisting >>>>of >>>>around 250 Kanji, one weekend experiment would be to try opening the >>>>file >>>>under Windows 98 (Japanese version of course). But really I'll consider >>>>it >>>>close enough if it works under Windows 2000, XP, 2003, and Vista beta. >>>>I >>>>haven't had time to test it and I do believe that mail. >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |