| T O P I C R E V I E W |
| Scot |
Posted - Jun 04 2022 : 12:38:59 PM
I love the Code Inspection feature... usually.
But when I happen to be working on C language code (almost always someone else's), Code Inspection should NOT be recommending changes that are specific to C++.
For example, you can't change NULL to nullptr or typedef to using in C.
If the toolset I'm using does not support the newer headers like <cstring> instead of <string.h>, it shouldn't be suggested.
I think VAX is sophisticated enough to know these things, right? |
| 18 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jun 13 2022 : 1:05:55 PM
As far as I can tell the problem here was Code Inspection not knowing the return type for the memalloc function. Because of this it was not sure how to treat the NULL, so it wasn't being picked up. Nothing to do with the ligatures, which is reassuring. |
| feline |
Posted - Jun 13 2022 : 07:42:46 AM
I have the sample, many thanks:
case=148232 |
| Scot |
Posted - Jun 10 2022 : 2:10:09 PM
yes, I'll send code via email. It belongs to a client of mine, so I need you to protect and restrict access just for your testing.
|
| feline |
Posted - Jun 10 2022 : 12:27:15 PM
I had no idea that happened, live and learn. I have set up a test here, in C++, with both 0 and NULL, and changing the font, thus enabling ligatures, has no effect on Code Inspection for me. All of the NULL's are being picked up, when they are part of a direct comparison or assignment.
So while the ligature happens where the bug shows up, it doesn't seem to be a factor.
Would it be possible to get a copy of one of the files where this bug happens, when it is called .C, for testing purposes, to try and work out what is going wrong here? I appreciate this is often not possible, but it's worth asking on the off chance that it is possible. If it was possible I would only be interested in pinning down the bug in Code Inspection, as a simple test case, and the file would not be used for anything else.
If it was possible please send me the files via email:
[email protected]
including this thread ID or URL in the description, so we can match it up. |
| Scot |
Posted - Jun 10 2022 : 11:42:35 AM
I am using "Cascadia Code" font. See this Visual Studio article:
https://docs.microsoft.com/en-us/visualstudio/ide/how-to-change-fonts-and-colors-in-visual-studio?view=vs-2022#use-the-cascadia-code-font
|
| feline |
Posted - Jun 10 2022 : 06:01:29 AM
The screen shot suggests that the ligatures are a problem, but that's just a theory at the moment. What font are you using? Is there an IDE setting I need to enable for this to happen? |
| Scot |
Posted - Jun 08 2022 : 1:14:23 PM
So, are you saying that the VA Code Inspection feature is somehow being thrown off by the ligatures in the text editor? I notice in the examples I pasted above that it's failing to see the "NULL" on the lines where the original programmer did those (abhorrent) assignments within conditional expressions. this includes the lines with "==", not just "!=". Could that be related? |
| Scot |
Posted - Jun 08 2022 : 12:56:58 PM
Thanks for discovering the .c vs .C bug!
[I went to the root folder of my sources and executed this from a command prompt to rename all the files with *.C extension to *c: "for /r %f in (*.C) do ren %f *.c"]
As for the not equals operator (it also does this for the <= and >= and other things), this is just a neat feature ("ligatures") of the text editor when the font in use supports it. |
| feline |
Posted - Jun 08 2022 : 08:09:32 AM
I forgot to list the case for checking if a header file is included in a C++ file, which is:
case=148221
Larger screen shots can be sent via email if that is easier.
Thank you for the screen shots, it turns out, very surprisingly, that the case of the file extension matters. If the file is a .c file, lower case, then Code Inspection treats it as C, but if the file is a .C file, upper case, then Code Inspection treats it as C++, even though it is still being compiled as C, not C++. I have put in a bug report for this:
case=148224
The other thing that really stands out in the screen shots is the not equals operator, what is going on there? That is an equals sign with a line through it. Is this something strange your font is doing? Is this a unicode character? How does this compile? That is not the correct character sequence for not equals, so the fact that this "invalid" code is appearing where the NULL underlining starts / stops suggests that it is related. |
| Scot |
Posted - Jun 07 2022 : 11:54:21 AM
To answer your question about whether included header files might be confusing it, here are some screen shots that demonstrate how VA is confused from the very beginning sometimes.
This first image is at the beginning of the .c file, and you can see that it is recommending newer CRT headers than the ones available for this toolset. If I switch to these new headers, I get compile errors:
Ughhh! Limit of only 100KB for an image file!?!?!?! you're making it hard to show a good screen shot!!
These next two images show how some NULLs are not underlined, and then some later ones are. Or vice versa, some are underlined and then some are not:
|
| feline |
Posted - Jun 07 2022 : 11:37:22 AM
I have put in a feature request for Code Inspection to check if a .h file is included by any .c files, and to treat the file as C rather than C++ if any such includes are found. Not perfect, but if done it should help. |
| feline |
Posted - Jun 07 2022 : 06:37:23 AM
If it is easier, you can email me at
[email protected]
including this thread ID or URL in the description, so we can match it up. This way images and any sample files you might have can easily be attached.
To attach images to the forum, instead of using the quick reply field at the bottom of the page, use the "Reply to Topic" link to get the reply field with the editing button toolbar. In the 3rd block of toolbar buttons, just to the right of the button labelled "HR" is the attach / upload image button, which will let you attach an image to your reply.
I am testing here in a solution with several projects, that is a mixture of C files, C++ code, C# and even VB.NET, so having a mixture of things in the solution should not matter.
Code Inspection is run on the single open file, but we do pick up context from your solution, so the #include statements can be worked out, and preprocessor directives can be understood.
First a "stupid" question, does the code compile, and is it being compiled inside Visual Studio, or via a different compiler? If code does not currently compile then you can get odd results from any tool parsing the code, so it's worth asking.
If you have the time could you please make a new, default C++ console solution, something incredibly simple, then copy one of your .c files that has lots of incorrect suggestions over to the new solution, and see if you still get the problem then?
If you do then something inside the file would seem to be the trigger. If not, then I would guess that one of the #include statements contains the trigger, but that's just a guess.
Having different results at different points in the same file is even more confusing though. Do you have #include statements part way through the .c files where this is happening?
If you look at the VA Code Inspection Results window, do you see the same problem? I am wondering if you are seeing a display problem as well, where Code Inspection is picking up all instances of NULL, but only some of them are being marked in the editor. |
| Scot |
Posted - Jun 06 2022 : 1:49:48 PM
I've been perusing the sources to look for a commonality, and learning that it's even less predictable. I have some .c files where this is not happening, and other .c files in the same project where it is. Furthermore, I have found some files where it is only happening part of the time!
I have a screen shot of some of a file where there are multiple instances of the word NULL being used for a null pointer value, but two of the instances are NOT underlined by Code Inspection, while the others are! How can I send this screenshot to this forum? |
| Scot |
Posted - Jun 06 2022 : 1:37:47 PM
I have a solution with 31 projects. Only a couple have some C++ (.cpp) files. The vast majority are C (.c) files. If this were happening only in .h files, I wouldn't have even brought it up. These are absolutely .c C language files, being compiled in that language.
This is Visual Studio 2022 (17.2.3) with VA version 10.9.2451.0. I have hundreds of examples I could show you.
Perhaps the presence of some C++ .cpp files in the build is triggering VA to think it's all C++?? That would be a bug, but if your testing doesn't have a mixture, maybe that explains why you don't repro. |
| feline |
Posted - Jun 06 2022 : 1:19:29 PM
Which IDE and version of VA are you using?
I am definitely not seeing this happening in .c files here, so I wonder why we are getting different results. |
| feline |
Posted - Jun 06 2022 : 1:18:34 PM
I have reproduced Code Inspection suggesting typedef into using, and 0 into nullptr, but only in a .h file, it does not happen for me in a .c file.
The problem with a .h file is that we don't know if it is being compiled as C or C++, and VA is treating it as C++.
Does your solution contain any C++ code, or is it a pure C solution? A header file can be included in both C and C++ files, so seeing it included in a C file doesn't mean that it isn't also compiled as C++ somewhere else, but it does mean that we should limit ourselves to treating it as C, so as not to break the C file include.
When / where is the header file being suggested? Is this via VA's Add Include command, or something else? |
| Scot |
Posted - Jun 06 2022 : 12:51:07 PM
These are .c files, being compiled as C language. |
| feline |
Posted - Jun 06 2022 : 05:41:22 AM
What file extension are you seeing this in? Is it a header file or a code file? |
|
|
