Undeclared identifier error in file "xlocnum"
in [MFC]
|
From: Joseph M. Newcomer on 7 Jul 2005 02:49 I had issues with strcat and strcpy in 1975, and nothing in the intervening 30 years has changed the fact that they are exceptionally poorly designed. I have never liked them, and now that I have CString, I never use them (what never? Well, hardly ever...) As I indicated, you have done something that includes the safe-string library; this redefines all those crappy old functions to generate warning messages, and provides for intelligently-designed alternatives. That's why a new project won't cause problems; but include the safe-string library and you'll get the problems. Note that when Microsoft did a code audit of Windows as part of their security effort, several THOUSAND potential buffer overflow exploits were identified as the result of strcpy and strcat. This came as no surprise to me. (I've heard numbers like 5000 and 8000 quoted in some newsgroups, but I have no inside information to verify any of these numbers. But they are quite credible). Since there is little or no reason to use either strcpy or strcat these days, it is better to adopt safe programming practices. I very nearly have the safe-string strcpy and strcat memorized at this point, mostly because I so rarely need them that I don't have to write such functions very often, and really don't use strcpy/strcat any longer. joe On Wed, 6 Jul 2005 18:01:02 -0700, "Yasoo" <Yasoo(a)discussions.microsoft.com> wrote: >Joe - > > Myself, I have no issues with strcat,strcpy,sprintf/etc. I actually like >them. I still don't understadnd why I am getting the error - I never have >before. I thought maybe installing the SDK might have something to do with >it, but I can create a new project as usual and use strcat just fine. >Something about the sample project? An include file that #defines something >which in turn will give me that error. I went hand by hand and switched >them, but I'd rather know how to tell it strcat is ok to use. Do you know >how? > >"Joseph M. Newcomer" wrote: > >> Actually, you should not be using sprintf any longer. This antiquated and dangerous >> function has now been replaced by the safe-string version. There is a redefinition of all >> the antique unsafe functions if you include the safe-string library that causes this >> message to be put out. Since you are already including the library (which causes this >> message), the best solution would be to follow its advice and replace sprintf with the >> safe-string version. For that matter, why are you using sprintf at all in an MFC program? >> Use CString::Format! >> >> It is an apalling state of affairs when it took 30 years to replace sprtinf with something >> intelligent. I was disgusted by strcat/strcpy/sprintf back in 1975 and I still am today. >> >> (In a fascinating exercise, I finally had to take a program I wrote in 1984, in C, and >> rewrite it, since the old MS-DOS program it interfaced to no longer operates, and I've >> lost the installation disks. What amazes me is the amount of effort I went through back >> then to implement my own safe-string functions. There are even comments in it indicating >> that sprintf is dangerous but I didn't know how to implement a safe-sprintf.) >> joe >> >> On Wed, 6 Jul 2005 06:42:02 -0700, "Yasoo" <Yasoo(a)discussions.microsoft.com> wrote: >> >> >I installed the Platform SDK and DX9.0 SDK. I am trying to compile a sample >> >project and I get the following error: >> > >> > >> >c:\program files\microsoft visual studio\vc98\include\xlocnum(481) : error >> >C2065: 'sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA' : undeclared >> >identifier >> >c:\program files\microsoft visual studio\vc98\include\xlocnum(479) : while >> >compiling class-template member function 'class >> >std:streambuf_iterator<char,struct std::char_traits<char> > __thiscall >> >std::num_put<char,class std:streambuf_itera >> >tor<char,struct std::char_traits<char> > >::do_put(class >> >std:streambuf_iterator<char,struct std::char_traits<char> >,class >> >std::ios_base &,char,long) const' >> > >> > >> >Anyone know what this might be? I put the xlocnum file that resides the PSDK >> >subdirectory (it's a newer file) in the project directory thinking the newer >> >xlocnum might work, but it returns the same errors. >> > >> >Also, I set up the search paths in "Options" on the "Directories" tab for >> >the SDK directories, but it still finds the "xlocnum" file in my Visual >> >Studio directory even though I moved the SDK directories to the top of the >> >list (for includes, libraries, executables, and souce). >> >> 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: Kurt Grittner on 7 Jul 2005 11:43 Hi Joe, Well, there is still a reason to use those crappy old functions. If your code is used on other platforms and by other compilers you will do much less re-coding if you use those tired old workhorses. -Kurt On Thu, 07 Jul 2005 02:49:59 -0400, Joseph M. Newcomer <newcomer(a)flounder.com> wrote: >I had issues with strcat and strcpy in 1975, and nothing in the intervening 30 years has >changed the fact that they are exceptionally poorly designed. I have never liked them, and >now that I have CString, I never use them (what never? Well, hardly ever...) > >As I indicated, you have done something that includes the safe-string library; this >redefines all those crappy old functions to generate warning messages, and provides for >intelligently-designed alternatives. That's why a new project won't cause problems; but >include the safe-string library and you'll get the problems. > >Note that when Microsoft did a code audit of Windows as part of their security effort, >several THOUSAND potential buffer overflow exploits were identified as the result of >strcpy and strcat. This came as no surprise to me. (I've heard numbers like 5000 and 8000 >quoted in some newsgroups, but I have no inside information to verify any of these >numbers. But they are quite credible). Since there is little or no reason to use either >strcpy or strcat these days, it is better to adopt safe programming practices. I very >nearly have the safe-string strcpy and strcat memorized at this point, mostly because I so >rarely need them that I don't have to write such functions very often, and really don't >use strcpy/strcat any longer. > joe >
From: Scot T Brennecke on 7 Jul 2005 13:31 Those crappy old functions can be dangerous, as you know. Obviously, experienced and disciplined programmers can use them without trouble, but it's very easy to make mistakes and open the door for hackers to exploit potential buffer overruns. If you're not developing for Windows, you can still use the std::string class in the Standard Template Library. "Kurt Grittner" <grittkmg_NO_SPAM_(a)mailbag.com> wrote in message news:rriqc118os5d5bb0jd9t1bg5mvafup5rhu(a)4ax.com... > Hi Joe, > > Well, there is still a reason to use those crappy old functions. If > your code is used on other platforms and by other compilers you will > do much less re-coding if you use those tired old workhorses. > > -Kurt
From: Kurt Grittner on 7 Jul 2005 16:10 Hi Scot, On platforms like TI 54x family of DSPs there is no STL because the compiler is C, not C++. When I use these sort of functions it's always something like this: (where pml is a pointer to a structure) memset(pml->FixedLenItem, 0, sizeof(pml->FixedLenItem)); strncpy(pml->FixedLenItem, lpszNewValue, sizeof(pml->FixedLenItem)-1); This leaves nice clean zeros in the unused bytes, makes sure that the dest is terminated, and avoids overruning the destination allocation. -Kurt On Thu, 7 Jul 2005 12:31:42 -0500, "Scot T Brennecke" <ScotBspamhater(a)MVPs.org> wrote: >Those crappy old functions can be dangerous, as you know. Obviously, experienced and disciplined >programmers can use them without trouble, but it's very easy to make mistakes and open the door for >hackers to exploit potential buffer overruns. If you're not developing for Windows, you can still >use the std::string class in the Standard Template Library. > >"Kurt Grittner" <grittkmg_NO_SPAM_(a)mailbag.com> wrote in message >news:rriqc118os5d5bb0jd9t1bg5mvafup5rhu(a)4ax.com... >> Hi Joe, >> >> Well, there is still a reason to use those crappy old functions. If >> your code is used on other platforms and by other compilers you will >> do much less re-coding if you use those tired old workhorses. >> >> -Kurt >
From: Joseph M. Newcomer on 7 Jul 2005 16:09
Other platforms exist? Actually, I once wrote a portable safe-string library so that my code could run on both VMW and Unix. It was worth the effort. About two weeks after I delivered the product, one of their programmers, while using my library, made a mistake, and was pleased that my library caught it. Note also that std::string is also portable. But if I do any string copies for any reason, I will use _tcscpy (it is trivial to replicate tchar.h functionality in a portable fashion). And if I do it, it is because I have ALREADY checked the target butter length to make sure it already fit. I gave up on pretending that these functions are reliable back in the late 1980s. joe On Thu, 07 Jul 2005 10:43:51 -0500, Kurt Grittner <grittkmg_NO_SPAM_(a)mailbag.com> wrote: >Hi Joe, > >Well, there is still a reason to use those crappy old functions. If >your code is used on other platforms and by other compilers you will >do much less re-coding if you use those tired old workhorses. > >-Kurt > >On Thu, 07 Jul 2005 02:49:59 -0400, Joseph M. Newcomer ><newcomer(a)flounder.com> wrote: > >>I had issues with strcat and strcpy in 1975, and nothing in the intervening 30 years has >>changed the fact that they are exceptionally poorly designed. I have never liked them, and >>now that I have CString, I never use them (what never? Well, hardly ever...) >> >>As I indicated, you have done something that includes the safe-string library; this >>redefines all those crappy old functions to generate warning messages, and provides for >>intelligently-designed alternatives. That's why a new project won't cause problems; but >>include the safe-string library and you'll get the problems. >> >>Note that when Microsoft did a code audit of Windows as part of their security effort, >>several THOUSAND potential buffer overflow exploits were identified as the result of >>strcpy and strcat. This came as no surprise to me. (I've heard numbers like 5000 and 8000 >>quoted in some newsgroups, but I have no inside information to verify any of these >>numbers. But they are quite credible). Since there is little or no reason to use either >>strcpy or strcat these days, it is better to adopt safe programming practices. I very >>nearly have the safe-string strcpy and strcat memorized at this point, mostly because I so >>rarely need them that I don't have to write such functions very often, and really don't >>use strcpy/strcat any longer. >> joe >> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |