It started as it had started in various projects before: a developer asking why this earns a warning in that file, but not in some header file. I checked with -vf and sure, the quiet header showed up as a library header. I searched the configuration for any +libdir directive or similiar when the familiarity of this problem struck me like thunder. So here this old but still current article goes:
Say you are using some libraries in your project and have disabled warnings from the headers of the libraries using the -wlib, -elib, or -elibsym options. Some of the platform configuration files created by Gimpel have a lot of -elib options, for example the ones for MS Windows.
To specify which header files are library header files, you use the +libclass, +libdir, +libh, and -library options.
Now here is the catch: the default setting for the +libclass option might classify most of your own header files as library headers and thus apply the relaxed rules for library code to your own code. If warnings appear or vanish when you shift code from one header to another without any apparent reason, it might got you too.
You can easily check if there is a problem with the classification of library headers using the -vf option: PC-Lint outputs for every header file whether it thinks it's a library header or not. You might be in for a surprise!
The default setting for +libclass is (foreign,angle), which means that all headers found via include path and all headers included with angles instead of quotes are library header files (if the -libh and -libdir options don't say otherwise).
This default setting is unfortunate, because I have seen a lot of projects where header files were put into separate directories named "inc" or "public" or something similar and were found via include path. If this holds for your project too, you'll want to change the configuration to +libclass(angle) or +libclass().