|
Thank you.
modified 26-Jul-20 2:21am.
|
|
|
|
|
_Flaviu wrote: sData = CString((LPCTSTR)arrByte.GetData(), arrByte.GetSize());
Note that conversion from byte array to CString may give you an unexpected result in some cases, also when compiling as MBCS.
For instance when the byte array contains one or more zero bytes. In such a case you will get a truncated string!
|
|
|
|
|
This is the full warning in question:
warning C6385: Reading invalid data from 'lines': the readable size is '(unsigned int)*4+4' bytes, but '8' bytes may be read.
I just (finally) converted a VS2013 project to VS2019, and as part of the cleanup I've been running the code analysis to help me spot issues. Below is a minimalist version of an oddity I found.
So here's the case that started the journey. You can assume m_iNumLines is a UINT greater than 0; checking for this and other error conditions (e.g. that the pointer is not NULL) did not eliminate the warning. Simplified for clarity, this is verbatim code that triggered the warning:
void CTestClass::SetText()
{
CString* lines = new CString[m_iNumLines];
for (UINT i = 0; i < m_iNumLines; i++)
{
lines[i] = "TestString";
}
delete[] lines;
}
I first tried covering every last (even absurd) error case to try and eliminate the warning, but changing lines[i] to *(lines + i) did it:
void CTestClass::SetText()
{
CString* lines = new CString[m_iNumLines];
for (UINT i = 0; i < m_iNumLines; i++)
{
*(lines + i) = "TestString";
}
delete[] lines;
}
I'm not sure what about handling of CStrings & pointers would make that an improvement. But here's what really baked my noodle. If I leave both lines in - even with the code that triggered thee warning first - I no longer get the warning:
void CTestClass::SetText()
{
CString* lines = new CString[m_iNumLines];
for (UINT i = 0; i < m_iNumLines; i++)
{
lines[i] = "TestString";
*(lines + i) = "TestString2";
}
delete[] lines;
}
I also get no warning if I swapped the order (thinking maybe optimization - even in a debug build - made the first line do nothing).
In searching I found others getting this warning also when using CStrings, but in situations much more convoluted than this, and I didn't see how it explained my case. Also I get the same results when using std::string, for what it's worth.
Look at me still talking when there's science to do
When I look out there it makes me glad I'm not you
|
|
|
|
|
I think the issue is that the variable lines is a pointer to an array of CString objects, it is not an array of pointers.
After further tests (non-MFC) I cannot get it to fail, or produce any error messages.
modified 24-Jul-20 4:58am.
|
|
|
|
|
FWIW, Visual Studio's C++ analysis is so bad, I keep it turned off. (Yes, it can find errors, but the number of false positives makes it pretty much worthless.)
|
|
|
|
|
not sure where to post this but i have a number of old projects that build pretty well with visual studio 2003 and 2005
but i dont want to jump around between two versions, i want to use the latest version of VS for both projects
my real problem is that VS2019 platform toolset option doesnt have V71 or V80
anyway i can point it to the actual versions i have already installed to build the projects?
thanks
|
|
|
|
|
hmd-omani wrote: my real problem is that VS2019 platform toolset option doesnt have V71 or V80
Then you will have to rebuild your old projects/solutions using the latest toolset!
|
|
|
|
|
is there no way to manually add those toolsets?
|
|
|
|
|
|
You should be able to select whatever toolsets are installed on your system, from the Project properties of Visual Studio 2019. However, it is advisable to use the latest one which will contain all the most up to date fixes and enhancements, and be fully compatible with the latest version of Windows.
|
|
|
|
|
it shows v90 and if i try to build using that it will say you need to install vc2008
so i guess it doesnt have to do with what you have installed on your system cuz if that was true than v71 & v80 would show up 
|
|
|
|
|
I guess that is down to the fact that there have been major changes since VS2003 and VS2005. But, as I mentioned above, you should use the latest toolset that is available.
|
|
|
|
|
it compiled for one of the projects after some tinkering 
i had to change the debug source files and point them to VC2003
added _CRT_SECURE_NO_DEPRECATE & _XKEYCHECK_H in preprocessors definitions
and fixed some codes
it runs even better than before, i have no clue how or why 
ill try & do the same to the other projects and maybe i will get lucky
|
|
|
|
|
Why do you insist on using out of date toolsets? Whatever short term improvements you might see there is a potential for major problems suddenly appearing.
|
|
|
|
|
im not insisting on anything, im just a hobbyist, what choice do i have?
im just trying to make working with these projects easier.
if you like i can send you the codes and you can fix them for me, but i dont think you or anyone here would do that, so here i am only asking questions.
|
|
|
|
|
hmd-omani wrote: what choice do i have?
As I keep telling you, the simple choice: use the toolset that goes with the version of Visual Studio that you are using.
|
|
|
|
|
so far so good but with my last project i got this warning c4474 saying too many arguments
sscanf(parm, "%%.2f", &f );
i added the extra % and it removed one warning already
any clues?
|
|
|
|
|
Too many % characters there. Remember in a printf/scanf format the % is the control character, so two of them means print (or read) a single "%" character. So in your call it expects to read a string of the form "%.2f", and requires no parameters. It should be:
sscanf(parm, "%5f", &f );
[edit]
The width value for scanf indicates the maximum number of characters to read for that field, so does not require the dot prefix, but should be large enough for the largest number.
See updated code.
[/edit]
modified 21-Jul-20 16:22pm.
|
|
|
|
|
why change the 2 to 5?
i removed the dot between % and 2 and it worked, i dont know if thats fine or not if i kept at 2?
|
|
|
|
|
Because that is the maximum number of characters it will scan. So %2f will not work for 1.75, or 11.6 for example.
[edit]
Try this code, it will show you what I mean:
char zzz[32];
char* pp = "23.58";
float ff;
sscanf(pp, "%2f%s", &ff, zzz);
printf("Number is: %.2f\n", ff);
printf("String is: %s\n", zzz);
[/edit]
modified 22-Jul-20 7:53am.
|
|
|
|
|
That’s a good example of why you should upgrade to a new toolset: sscanf is a variadic function with a variable number of arguments. Older toolsets didn’t bother to do any analysis on the arguments while the newer ones interpret the format string the same way it would be interpreted at runtime and check if the arguments match. In your case they don’t because the ‘%’ sign looses it’s special function if it is escaped by another ‘%’ sign. VC19 is just trying to warn you about a probable bug in your code.
Mircea
|
|
|
|
|
i didn't change the platform toolsets, only the debug source files
|
|
|
|
|
Not sure what you mean by changing only the debug source. There are however two problems with your format specifier:
- sscanf formats do not have a point for number of decimal places (unlike printf formats).
- percent sign must be escaped to read a percent sign from the input.
So, if you want to read something like "%12.34", the correct sscanf format is "%%%5f".
VS2019 warns you if you are missing the triple percent because the last argument of sscanf will not used.
Mircea
|
|
|
|
|
SOLVED case closed
As expected - pkg-config DOES NOT integrate with just any Eclipse version / release.
I got it working as expected in 2018-09!
Sorry for wasting everybody time.
Cheers
This is really driving me nuts.
The verbose output form complier and project GUI will show same
/usr/include....
However
only full path include file passes test
#include /usr/include/gtkmm-3.0/gtkmm.h
Including gtkmm.h by itself , will show
"unresolved inclusion"
#include "gtkmm.h"
On top of this - build is successful, no errors and it runs.
So "unresolved inclusion" error is no error ?
modified 22-Jul-20 13:06pm.
|
|
|
|
|
I can only assume that eclipse is doing something. Normally, a header file that can't be found results in a fatal error. If you really are using #include "gtkmm.h", maybe eclipse is searching the project directory for the include file and that is what is generating the warning message. GCC/G++ on the other hand, searches the project directory and then the normal system directories for "" delimited include files Include Syntax (The C Preprocessor) If it is the case that you're using #include "gtkmm.h" try changing to #include <gtkmm.h>, and see if that removes the warning.
Keep Calm and Carry On
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
