i have some source-files with SAL Annotations.
I looked in the Log View of cppcheck to see if i can do anything to get the maximum out of the analysis.
What i detected are messages like this: [foo\bar\MyString.h:1436] - debug - debug
Unknown type '_In_z_wchar_t'.
Unknown type '_In_z_wchar_t'.
The original code is this:
static MyTString toString( _In_z_ const wchar_t * s )
I wonder why cppcheck concatenates In_z and wchar_t and interprets this as a new type (maybe this is just an internal representation and i shouldn't care?).
Important to me is what cppcheck actually does with this code. Is the parameter ignored? Or the whole function?
Sure, it would be nice to just ignore all SAL annotations, but what is the best way to achieve this?
Any chance that there will be some sort of support for this? Maybe this could be done in a similar way to the .cfg files for the libraries. A file where one can enter all annotations to be ignored.
This way i wouldn't have to change the projects/sources to get them parsed correctly by cppcheck.
Best Regards
Sebastian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder why cppcheck concatenates In_z and wchar_t and interprets this as a new type (maybe this is just an internal representation and i shouldn't care?).
Off the top of my head.. I don't know.
Important to me is what cppcheck actually does with this code. Is the parameter ignored? Or the whole function?
It should perform much of the checking of the parameter and function anyway. missing types are treated as non-POD types in C++ code and as POD types in C code.
Sure, it would be nice to just ignore all SAL annotations, but what is the best way to achieve this?
you have two options:
* use --include
* use a .cfg file
however there is a --include bug in 1.68, we have fixed it so this will work better in 1.69.
I'd personally use --include if I wanted to have some special defines for checking my projects.
Any chance that there will be some sort of support for this? Maybe this could be done in a similar way to the .cfg files for the libraries. A file where one can enter all annotations to be ignored.
yes. if somebody creates a microsoft_sal.cfg I think we can add it in the repo. Here is a start:
I've created a microsoft_sal.cfg that works well for my current project.
I also added a part with the (old) Microsoft Header Annotations, that's not SAL Annotation as far as i know. Depending on how strict the cfg-name is, this part then should be removed/moved to another cfg.
I appreciate any comments :)
What author information do you want me to use when I add it to the repo? I need your first name and last name (this will be shown in our AUTHORS file later). And I need an email address also, it should be either a real email address that I could use to reach you later, or your-sourceforge-account@sourceforge.net.
Last edit: Daniel Marjamäki 2015-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
i have some source-files with SAL Annotations.
I looked in the Log View of cppcheck to see if i can do anything to get the maximum out of the analysis.
What i detected are messages like this:
[foo\bar\MyString.h:1436] - debug - debug
Unknown type '_In_z_wchar_t'.
Unknown type '_In_z_wchar_t'.
The original code is this:
I wonder why cppcheck concatenates In_z and wchar_t and interprets this as a new type (maybe this is just an internal representation and i shouldn't care?).
Important to me is what cppcheck actually does with this code. Is the parameter ignored? Or the whole function?
Sure, it would be nice to just ignore all SAL annotations, but what is the best way to achieve this?
Any chance that there will be some sort of support for this? Maybe this could be done in a similar way to the .cfg files for the libraries. A file where one can enter all annotations to be ignored.
This way i wouldn't have to change the projects/sources to get them parsed correctly by cppcheck.
Best Regards
Sebastian
Off the top of my head.. I don't know.
It should perform much of the checking of the parameter and function anyway. missing types are treated as non-POD types in C++ code and as POD types in C code.
you have two options:
* use --include
* use a .cfg file
however there is a --include bug in 1.68, we have fixed it so this will work better in 1.69.
I'd personally use --include if I wanted to have some special defines for checking my projects.
yes. if somebody creates a microsoft_sal.cfg I think we can add it in the repo. Here is a start:
Last edit: Daniel Marjamäki 2015-01-16
Thanks, this is great news, better than i would have expected ;)
Didn't know that 'trick' with define's in cfg files yet.
I will try it this way :)
I've created a microsoft_sal.cfg that works well for my current project.
I also added a part with the (old) Microsoft Header Annotations, that's not SAL Annotation as far as i know. Depending on how strict the cfg-name is, this part then should be removed/moved to another cfg.
I appreciate any comments :)
Thanks for the cfg file.
What author information do you want me to use when I add it to the repo? I need your first name and last name (this will be shown in our AUTHORS file later). And I need an email address also, it should be either a real email address that I could use to reach you later, or your-sourceforge-account@sourceforge.net.
Last edit: Daniel Marjamäki 2015-01-21
Ok, great. You can use: Sebastian Matuschka sebastian.matuschka@gmail.com
I added the microsoft_sal.cfg file with:
http://github.com/danmar/cppcheck/commit/6a0a92b3a6d9629d4bd1aedb0915b7eda81fa99c