Showing results for 
Search instead for 
Did you mean: 

Undocumented pragmas

Maybe it can be useful to someone ... 
I like to compile my code with Warning level: All. It is one of my obsessions 😎.

This has the consequence that very often I have to disable the warnings in the list that you can pull up in the "build Options" panel, which is quite boring, and besides, the change is global for the whole project.
NI documents some pragmas, which have the effect of disabling very few of these warnings.

#pragma DisableUninitLocalsChecking
#pragma DisableAssignInConditional
#pragma DisableUnreferencedIdentifiers

I just discovered that Clang-style pragmas are supported, too
So for example

#pragma clang diagnostic ignored "-Wstrict-prototypes"

disables the "-Wstrict-prototypes".


#pragma clang diagnostic push
#pragma clang diagnostic pop

have the fairly obvious function of saving the current warning situation to a stack and restoring it later.


Windows include files are full of violations, to get a "zero warning" compilation I prefaced #include "windows.h" with
this block of instructions

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wbad-function-cast"
#pragma clang diagnostic ignored "-Wused-but-marked-unused"
#pragma clang diagnostic ignored "-Wswitch-enum"
#pragma clang diagnostic ignored "-Wundef"
#pragma clang diagnostic ignored "-Wunknown-pragmas"
#pragma clang diagnostic ignored "-Wmicrosoft-enum-value"
#pragma clang diagnostic ignored "-Wclang"
#pragma clang diagnostic ignored "-Wstrict-prototypes"
#pragma clang diagnostic ignored "-Wunused-parameter"
#pragma clang diagnostic ignored "-Wpadded"
#pragma clang diagnostic ignored "-Wignored-attributes"
#pragma clang diagnostic ignored "-Wtypecheck-convert"

and after all stock #include statements, a nice 

#pragma clang diagnostic pop

reenables all the warnings, so my paranoid approach to warnings works perfectly, but only on my code. 

At present I've not explored if the other variations works, too. I don't need them. I leave as an exercise to my two readers 😉.
Let me know, just in case.

#pragma clang diagnostic warning "-Wname"
#pragma clang diagnostic error "-Wname"
#pragma clang diagnostic fatal "-Wname"


Carlo A.

Message 1 of 7

nice post, thanks from reader 1 😉

0 Kudos
Message 2 of 7

@Wolfgang: thanks a lot, now waiting for #2 reader 😉

I have a follow-up on this topic.

First of all, the #pragma clang diagnostic warning/error/fatal works, too.

There is a much simpler solution than include a big list of warnings from system includes to be ignored.
Guess how? Another undocumented (in CVI, of course) pragma.


#pragma clang system_header


If you put it in an include file, that may be includes all the system include files, any warning will be silenced until the end of the file.

The effect is different from 


#pragma clang diagnostic ignored "-Wall"


that silences all the warnings until the end of the source file that contains directly or indirectly (i.e via an #include) this statement.
The scope is different.

Have fun...


Carlo A.

Message 3 of 7

I'm afraid I'm reader #3. Sorry for messing up your forecast although maybe Roberto is on vacation so he may end up being reader #3. 😀


I'm not sure I would call it really undocumented. We all know that LabWindows/CVI uses clang under the hood since quite a few versions. So most of what applies to clang also applies to the LabWindows/CVI compiler backend. And it makes sense that they didn't spend any time to rip out such features, just to be conformant to the non-existing LabWindows/CVI documentation about those features. 😁

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 7

@rolfk I'm more than glad to have other readers, other than Wolfgang and Roberto. It was so obvious I was thinking to them? 🤣

Back on track: these pragmas are definitely documented elsewhere in the clang / GNU documentation. They are not documented in the NI manuals, like many other "hidden" clang / gnu features they have kindly left in place.
What I found a little odd is that I have to experiment to know what is supported and what isn't, the "C Language Extension" page being barely a collection of links. For example: on that page it says that the pragmas accepted by GCC are supported, and not the clang ones as well, and - as far as I can see - they are not exactly the same.
I also understand that that page could be a portal to other dimensions of discomfort for less experienced users.


Carlo A.

0 Kudos
Message 5 of 7

GNU documentation is generally great and quite extensive but it only documents a certain snapshot of the GNU software tools at a certain version. Since the whole software is continuously further developed, even the GNU documentation can be out of date and you also have to consider that there are many places that take a snapshot of the official canonical documentation and post it and then let it rest in peace on their servers.


So what you find online about certain features can vary greatly, depending on where you look and of course you also have to consider that the version used in LabWindows/CVI certainly isn't the greatest and latest. They took a snapshot of the clang sources and adapted and integrated it into the LabWindows/CVI tool chain and updating it to a newer version NEVER is a copy and recompile operation only. Headers need to be massaged, defines modified, build scripts adapted, and, and, and, and.. to make it work with the existing LabWindows/CVI interface, so they don't do that on a hunch but only if there are real advantages to be gained from using a new release.


But as it seems, we will not have to worry about more such changes in the future. LabWindows/CVI 2020 seems to be the last version that has seen the light of this world.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 7

Ok, ok, it's true: I'm on vacations now, but you can count me as reader #3!  😉

Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
If I have helped you, why not giving me a kudos?
0 Kudos
Message 7 of 7