Enabling PREfast static analysis checks in an existing project I have yields many instances of the following:
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\WindowsNumerics.inl(2375) : warning C6101: Returning uninitialized memory ‘*scale’. A successful path through the function does not set the named Out parameter. Annotate this function with Success(return) if returning FALSE indicates failure.: Lines: 2375, 2379, 2381, 2383, 2375
This may be triggered by including any of the following headers:
#include <winrt/Windows.Storage.FileProperties.h>
#include <winrt/Windows.Media.Capture.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.Data.Json.h>
but all instances I've seen so far seem common to WindowsNumerics.inl.
This prevents us from enabling PREfast on winrt projects without adding specific suppressions in our code as a workaround. Should we expect winrt headers to pass these checks? Will this be addressed in a future release?
This seems to be a case of the header missing _Success_(return != false) annotation on the invert and decompose functions.
This bug is still present in the latest public Windows SDK (22000).
I'll see if I can find the owner to file a bug for a future Windows SDK release.
You haven't mentioned which toolset you are using, but you should take a look at /external switch.
Related
I'm working on a CMake-based project that contains both C++ and CUDA source files, and has some headers meant to be included by both languages.
For these header files, I'd like to see the result of highlighting and syntax checking as close as possible to what NVCC, the CUDA compiler, would see, so for example, I'd like to have the preprocessor symbol __CUDACC__ be defined.
It's important to me that CMake does not have such a symbol defined, because it's really an internal symbol of the NVCC toolchain that I need for syntax-checking purposes.
I've tried "Tools->C++->Additional preprocessor directives" and it seems to have no effect. I've also tried a file named CMakeLists.txt.config which seems to have no effect either.
I'd love a suggestion for this.
To reiterate, I'm looking for a way to set a define (CPP symbol) visible to to the syntax-checking system only.
After further digging I found an attribute specific to the Clang analyzer that is defined during the analysis performed for syntax checking but not during compilation.
Note that this is purely because my project compiles with GCC, while QT Creator's syntax checking runs through Clang.
// GCC and NVCC don't have __has_feature(), so we provide a fallback
#ifndef __has_feature
# define __has_feature(x) 0
#endif
#if __has_feature(attribute_analyzer_noreturn)
# define IN_CLANG_ANALYZER 1
#else
# define IN_CLANG_ANALYZER 0
#endif
This allows a clumsy hack as follows, which may or may not be useful, depending on one's needs. Pretty much the idea is that much like you'd
have Clang observe your code even if you compile with GCC, this achieves
something similar for files inteded to be used with NVCC.
#if IN_CLANG_ANALYZER and !defined(__CUDACC__)
# define __CUDACC__
# include <cuda_device_runtime_api.h>
# include <optix_device.h>
#endif
However the substantial problem remains that when compiling with Clang, all the above falls flat on its face, because clang++, the compiler, also defines the same feature as enabled.
What's needed to fix this is some kind of macro defined in the analyzer but not in Clang, and so far I've found none like this.
At first I had hoped __clang_analyzer__ would fit this need,
but according to my version of Qt Creator (6.0.2) the macro is not defined
during syntax checking, so we're back to square one.
I have an open source, Objective-C library that I maintain. It has been around for a long time, and I've always distributed it as an embeddable Xcode project that builds a framework, as well as through Carthage and Cocoapods. (The library in question is ORSSerialPort.)
I recently added support for installing it with Swift Package Manager (see this commit), by creating a Package.swift file. I was able to do so without making any source or structure changes, which was helpful because I need to continue to distribute it as a framework as well for the foreseeable future.
However, Xcode 12 included a new (or at least newly on by default?) warning when you do #import with double quotes in public headers in a framework. I had done that in a couple places, so switched to angle brackets as is correct for a framework (see this commit).
I've only now discovered that SwiftPM no longer builds the package because of that. It fails with the following error:
In file included from /Users/andrewmadsen/Developer/ORSSerialPort/Source/ORSSerialPort.m:28:
/Users/andrewmadsen/Developer/ORSSerialPort/Source/ORSSerialRequest.h:28:9: fatal error: 'ORSSerial/ORSSerialPacketDescriptor.h' file not found
#import <ORSSerial/ORSSerialPacketDescriptor.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
[0/1] Compiling ORSSerial ORSSerialPort.m
One possible solution (that does work, but is kinda gross), is to conditionalize any import with an #ifdef, then pass in a define in the cSettings argument when creating the target in Package.swift, but that seems kind of gross and unwieldy. In this project it's not bad, but in another project I have many, many more headers affected by this issue.
So, to the root of my question:
Is there a way to convince SPM to build an Objective-C package where the public headers use <> angle brackets to include other public headers in the package?
I've already tried specifying a header search path in cSettings, but this produces the same error:
.target(
name: "ORSSerial",
path: "Source",
exclude: ["ORSSerialBuffer.h"],
publicHeadersPath: ".",
cSettings: [
.headerSearchPath(".")
]
)
(All .h and .m files are in the same Source folder.)
I had the same issue recently. The only way I found to work around this was to change the includes to standard user-style includes
#import "ORSSerialPacketDescriptor.h"
Of course, this breaks the header for Objective-C clients. But since Swift uses the module map, you can still use it from Swift code.
Original questin: Is there any way to get what macros nw-gyp add to the build project by default?
I'm developing a nw addon and I've tried to link a custom static lib to .node DLL. However I found nw-gyp will add _HAS_ITERATOR_DEBUGGING=0 by default (It always appends to the addon project to override custom defines), which will affect the actual structure size for STL types (e.g. std::string).
So is there a way to get such macros node gyp added by default, or is there an easy way to make compiler's (maybe the whole toolchain, link tool etc.) configuration for both static lib and nw build project the same?
Now I've add _HAS_ITERATOR_DEBUGGING=0 to my lib and make it MT(D), and It seems to work fine, but I'm not sure if this is the right way. (Some other compiler settings may not cause compilation error but can crash in runtime)
Edit: Share some analysis to make my origin question clearer.
All current question is on Windows platform.
The _HAS_ITERATOR_DEBUGGING=0 is added even when I build nw addon in debug mode (with --debug), and this may be affected by the nw headers downloaded by nw-gyp. For example, headers download from http://node-webkit.s3.amazonaws.com/v0.49.2/nw-headers-v0.49.2.tar.gz , you will find 'defines': [ 'DEBUG', '_DEBUG', 'V8_ENABLE_CHECKS', '_HAS_ITERATOR_DEBUGGING=0' ] in common.gypi at line 288 in Debug_Base config section, and this is most likely inherit from https://github.com/nwjs/chromium.src (I guess here https://github.com/nwjs/chromium.src/blob/nw60/build/config/BUILD.gn#L130). So can it be concluded that Chrome add these defines for debug mode on purpose?
What is the problem _HAS_ITERATOR_DEBUGGING=0 in debug for me? Well, it affects the size for many STL classes (std::string, std::vector and etc.). So all debug lib that need to be linked to nw addon should be compiled with '_HAS_ITERATOR_DEBUGGING=0', otherwise compilation error will occur for static libs and runtime pointer problem crash (struct offset mismatch) for dynamic libs (of course it is not a good practice to use STL in dynamic lib headers, but if you can assume the toolchain same it will still work fine). But this is really hard for me when it comes to third-party binaries, I've got no sources for most of them, so I can't give a debug static lib with _HAS_ITERATOR_DEBUGGING=0 on. This is really frustrating when I need to debug the addon with lldb or VS, since all variables are optimized and you cannot debug their values.
Can I force _HAS_ITERATOR_DEBUGGING=1 for debug mode? As mentioned in origin question, it cannot be done normally like answer from #mmomtchev. A hack way to do is to add "/D _HAS_ITERATOR_DEBUGGING=1" to configurations->Debug->msvs_settings->VCLinkerTool->AdditionalOptions in gyp file for addon, this will append /D _HAS_ITERATOR_DEBUGGING=1 to the end of the compile command which override the former defination. But I'm not sure if this is a good workaround! I've checked v8 header files and have found some classes with std::string and std::vector members. I think force _HAS_ITERATOR_DEBUGGING will cause some problem if you use these classes, but for other classes it is safe (I've tested many cases, normal classes like v8::value v8::function work well). And it is not safe when cooperating with other addons. Let's assume one debug addon A and another release addon B need to communicate with each other, they agree on one C++ struct for data exchange. A common way is to let A to wrap a C++ struct instance to a JS object for user. and let user pass the JS object to B by calling methods provided by B (the JS object is one of the arguments), and then B unwrap the JS object from arguments and get the pointer of the C++ struct instance. All looks fine, but what if the C++ struct has std::string member? The sizes of same C++ struct for A and B are not the same. so B will crash when trying to access the member with type of std::string or std::vector. This is not an issue if _HAS_ITERATOR_DEBUGGING=0 is set for debug mode since _HAS_ITERATOR_DEBUGGING is always disabled for release, and I guess that's why nw addon can work with mixed production mode(debug an release) addons in common cases.
So my final question is: If it is not a good way to force _HAS_ITERATOR_DEBUGGING=1 for debug and I don't have source code for many external compiled lib binaries, does it mean I've no way to build a nw addon in debug mode? Athother possible way is to wrapper those libs with C style API and compile them to dynamic libs, but this is really huge work for me and is unacceptable.
Normally, _HAS_ITERATOR_DEBUGGING=0 is defined by default on all Release builds.
If you need to add macros, you need to add this section to the root of your gyp:
'defines': [ '_HAS_ITERATOR_DEBUGGING=0' ]
This question already has answers here:
AFNetworking.h file not found
(5 answers)
Closed 1 year ago.
#import <AFNetworking/AFNetworking.h>
I imported AFNetworking.h file to .m file but an error occurred like this:
'AFNetworking/AFNetworking.h' file not found
I deleted pods folder and Podfile.lock, and reinstalled Podfile but didn't solved. What should I do? (I opened the workspace file.)
Linking !== Copying.
there is C style #include ... and Objective-C style #import ...
both work almost the same..
where #import reads the header but does not include again if done once. As this can and does fail sometime (usually because mixing C,C++,Objc,Objc++ in different dialects) we often use #define rules to make sure the enclosed code is read once for sure and not again, which in turn works also when code is included and declared with #include. It would be included but not compiled twice.
#ifndef SOME_HumanReadableFlag_h
#define SOME_HumanReadableFlag_h
// ... your header code here..
#interface XyzObject : FromInheritedClass
#end
#endif
Now why does it matter?
It might happen that a #define rule enclosing the header files content hides the header from the viewpoint of other classes.. This can & does happen often when classes are not properly written with the end developers structure in mind. It might work on the workbench of the developer but not for everyone else implementing it.
Your error clearly tells "File not found .."
So first see what both import/include rules differentiate in general
#import <LibFrameworkName/LibFrameworkName.h>
means you have to link the framework or library, even if you developed one on your own in that project. The rule is relative to your project, LibFrameworkName is a Framework/Lib. Where if found somewhere #include <LibFrameworkName/LibFrameworkName.h> is not correct unless you want to c-style include this framework header into your binarys header, 2) tells you a bit about why..
#import "LibFrameworkName/LibFrameworkName.h"
means you have to copy/offer this header into your project with a subfolder with name LibFrameworkName. Once somewhere declared properly Xcode might find and apply the headers even if declared with the wrong rule later on in that specific class, you should also get a warning in the IDE then. In case of AFNetworking you dont want to copy System SDK Frameworks into your project, also not into third party frameworks unless you know what you do. This rule is relative to the files place in project structure, meaning here it would try to look out for some folder with name LibFrameworkName below the file that carries this rule.
what it says: because the Framework is not linked, the compiler tries to find it with the given name ignoring < & > so as if it where like 2) a file with that folder name, then will not find it and throws the error or warning.
To force the precompiler to parse thru some specific folders we use sometime the header search path to explicit tell where to find it. Widely used and mostly troublesome because it also hides wrongly defined rules to the developer as Xcode skips the still existing wrong import rules in code assuming it knows this headers already. Or it throws warnings while everything is actually fine. Other developers experience trouble then, the file structure and header list don't match at all. So keep in mind, when you can avoid making use of header search path lists, go for it. It also will and should not fix your issue.
'<AFNetworking/AFNetworking.h>' File not found means a Framework module is not known to your project. This header is part of a Framework.
Solution: You have to go to your Projects Settings and scroll down to Frameworks and Libraries, hit [+] below this list. It should open the dialog presenting all SDK from your choosen Project Target and all known Pods or known frameworks of your own project when you developed some. Search for the Framework or Lib by name, click it, hit "Add".. done..
From there - there are some options to get used to it..
Because Linking does not mean Copying into your Resources at compile time by default. Usually Xcode knows it does not have to copy System SDK into a projects Framework Folder, all macUsers have those Frameworks preinstalled on their system of course in the right version.. Linking against some specific folder like ${SOMEFLAGWHEREEVERTHISPOINTSTO}/AFNetworking/AFNetworking.framework/Headers is actually wrong unless someone wanted to overrule the systems framework header and maybe also binary.
So AFNetworking should not appear under Build Phases > Copy Bundle Ressources list but after the process above is done it will appear under Link Binary with Libraries, it might also be placed in Dependencies when Xcode needs to know for some Library/Framework it must have this to compile. Last mentioned option is because you could have a framework that adapts at runtime when some framework is missing or not available. So this Entry helps Xcode to figure out in which sorting it has to compile your stuff.
finding ${PODS_CONFIGURATION_BUILD_DIR}/AFNetworking/AFNetworking.framework/Headers in Header Search Paths there must be something wrong i guess.. because the framework is very likely not copied into the Pods folder. It should be relative to your SDKs folder that come with Xcode. The Linking process told above should fix that and you can erase that entry from your header search path then.
In my project I use different flags to run different code when dealing with multiple targets. Something like
#ifdef MY_FLAG
//do this
#else
//do this other
#endif
Now I'm on my way to take some code to an external library, but I don't want to compile different versions of the library for each flag, so the question is:
Is there a way to pass something like arguments that tells the library (or framework) from outside which code should run in a "global" manner?
What you're doing with #ifdef is establishing which code the compiler can see. So you're going to have to compile different versions for each flag, as libraries are linked against but are already compiled. I guess the question is more what you do with those on disk.
You can store multiple CPU architectures into a single static library. So any of those flags that are merely to do with whether you're targeting ARMv7, ARMv7s or i386 can be handled with a single library.
For the others you're probably going to have to produce different libraries. However that'll just be a matter of the shape of the disk footprint — you can use the project settings of any project you link against your libraries so that it links to a different version of the library depending on the build configuration.
One option is to have the framework provide some sort of initialization method or function that the user of the framework can call. This would tell the framework what "mode" it should run in. The client of the framework could call this at app startup.