I am working on SQLite File Encryption. I have added sqlCipher & crypto frameworks successfully in my project.
Now when I try to compile my application on this line
int rc = sqlite3_key(database, [key UTF8String], strlen([key UTF8String]));
it says Implicit declaration of function 'sqlite3_key'
So above line "implicit declaration" sounds to me like function is defined but not declared. But where I have to declared ?
While searching over Internet, under this article, it says like SQLite Encryption Extension(SEE) is not available publically. I have to purchase it of cost around $2000.
SEE -> http://www.hwaci.com/sw/sqlite/see.html
So this is the only reason I am getting Implicit declaration & False response while sqlite encryption process ?
If you are using SQLCipher, you need to define SQLITE_HAS_CODEC in your application's C Flags. Thats all.
Yes, that is the reason you are getting that compiler warning. The function sqlite3_key() is not defined in the version of libsqlite3 included with iOS. Adding in a function declaration isn't going to help-- it would fix that compiler warning, but it would just mean you'll get a linker error since the function isn't defined anywhere.
If you purchased SEE you could probably build your own copy of SQLite, embed it in your app, and just not use the system's libsqlite3. That this would mean you'd have to say "yes" when the app store submission process asks if your app includes encryption, meaning extra paperwork and time before you could submit the app. I'm not certain whether there's any clear indication of whether Apple would accept it even then-- probably they would, but they've been known to surprise people.
Related
While compiling and Xcode swift project for MacOS, not used functions are removed from the binary (removed by the optimizer I guess). Is there a way to tell the compiler to not remove unused functions, perhaps with a compiler option (--force-attribute?) so that even with optimization enabled those functions remain in the binary?
I know that if a global function is declared as public (public func test()) then it's not removed even if not used (Since it can be used by other modules), but I can't use public since that would export the symbol for that function.
Any suggestion?
If this is indeed removed by the optimiser, then the answer is two-fold.
The optimiser removes only things that it can prove are safely removable. So to make it not remove something, you remove something that the optimiser uses to prove removability.
For example, you can change the visibility of a function in the .bc file by running a pass that makes the functions externally callable. When a function is private to the .bc file (also called module) and not used, then the compiler can prove that nothing will ever call it. If it's visible beyong the .bc file, then the compiler must assume that something can come along later and call it, so the function has to be left alive.
This is really the generic answer to how to prevent an optimisation: Prevent the compiler from inferring that the optimisation is safe.
Writing and invoking a suitable pass is left as an exercise for the reader. Writing should be perhaps 20 lines of code, invoking… might be simple, or not, it depends on your setting. Quite often you can add a call to opt to your build system.
As I discovered, the solution here is to use a magic compiler flag -enable-private-imports (described here: "...Allows this module's internal and private API to be accessed") which basically add the function name to the list #llvm.used that you can see in the bitcode, the purpose of the list is:
If a symbol appears in the #llvm.used list, then the compiler,
assembler, and linker are required to treat the symbol as if there is
a reference to the symbol that it cannot see (which is why they have
to be named)
(cit.) As described here.
This solves my original problem as the private function even if not used anywhere and not being public, during compilation is not stripped out by the optimiser.
I have a Swift application that uses a module, and I need to call a global function that is in the application from the module, is this possible?
To perhaps explain a little better, this is a test app structure:
CallbackTestApp contains a function foo(), I would like to call it from Module1 or File, will swift allow this?
edit #1
More details have been requested on what is the background of my issue, hopefully, this will not turn out to be an XY situation.
There's a tool developed by my company that process the application source* code and in some places add function call (ignore the why etc, have to be generic here.). Those function calls are exactly to foo() which then does some magic (btw, no return value and no arguments are allowed), if the application does not use modules or if modules are excluded from the processing then all is fine (Linker does not complain that the function is not defined), if there are modules then nothing works since I did not found a way to inject foo() (yet).
*Not exactly the source code, actually the bitcode is processed, the tool get the source, use llvm toolchain to generate bitcode, do some more magic and then add the call to foo() by generating it's mangled name and adding a swiftcall
Not actually sure those additional details will help.
It's about the stm32 question ,now I want to compile the program about receiving and sending data through gpio in keils .when I build it ,there are always having some warning about
#223-D: function "usart1_send_byte" declared implicitly or #223-D:
function "usart1_send_byte" declared implicitly
I don't know how to define it,please help me .
It is in a header file, probably something similar to stm32f1xx.h, depending on your board. ST has just released an online course through Udemy, very good for beginning the microcontroller journey if you plan to continue with ST chips. Sign up through my.st.com , the forum there is also quite useful.
If your code compiles/links and works correctly, you have the actual implementation of usart1_send_byte somewhere. Your compiler warns, but linker can still link because it is existing somewhere.
Do a file search for usart1_send_byte and find the header file which the function is defined. Then include that header file to the source file that this warning appears.
I am running into a weird issue when trying to test for the existence of a symbol that is introduced in a newer version of the OS. I follow the Apple guidelines on using weak-linked symbols, i.e.
Check the availability of an external (extern) constant or a
notification name by explicitly comparing its address—and not the
symbol’s bare name—to NULL or nil.
To reproduce the issue, I am using the latest iOS 6 SDK on the latest Xcode 4.5.2, using the default compiler (Apple LLVM compiler 4.1). I weak-linked the Social framework (which is only available on iOS 6+). And I run this code on iOS 5.1 (the deployment target is lower than 6):
NSLog(#"%p", &SLServiceTypeFacebook);
if (&SLServiceTypeFacebook)
NSLog(#"Yes1");
if (&SLServiceTypeFacebook != NULL)
NSLog(#"Yes2");
The output is:
0x0
Yes1
Yes2
In other words, we can verify at runtime that the expression &SLServiceTypeFacebook evaluates to the value 0. Yet, if statements that test on this expression treat it as if it is true.
Update:
From this question, I found that this workaround works with no optimization, but not with optimization:
typeof(&SLServiceTypeFacebook) foo = &SLServiceTypeFacebook;
if (foo)
NSLog(#"Yes3"); // does not get executed on -O0, but does on any optimization
Update:
It appears that this problem does not exist with UIKit symbols. Running the following on iOS 4.3:
NSLog(#"%p", &UIKeyboardDidChangeFrameNotification);
if (&SLServiceTypeFacebook)
NSLog(#"Yes1");
if (&SLServiceTypeFacebook != NULL)
NSLog(#"Yes2");
The output is:
0x0
I hypothesize that the difference is that the UIKit symbol has a NS_AVAILABLE_IOS() macro next to it, so somehow the compiler handles it correctly. In the case of the Social framework symbol, it doesn't have a NS_AVAILABLE_IOS() macro since the entire Social framework itself is only available since iOS 6 (i.e. the symbol is available since the version of the framework, so I guess the don't need this macro?); but then the compiler does not handle the symbol correctly.
Are you sure you don't want to check that the SLRequest class exists instead of checking for this constant?
In any case, the issue is that the compiler is optimizing the test away (it interprets this as testing a constant expression which is true at compile time). You can circumvent this by reading this address into a local volatile variable. Or you could dynamically search for the symbol at runtime.
But I would consider just checking for the SLRequest class instead.
Here are at least these three options:
#include <dlfcn.h>
NSString* const * volatile check = &SLServiceTypeFacebook;
if (check != NULL)
NSLog(#"SLServiceTypeFacebook is defined");
// Another approach would be to call dlsym() at runtime
// to search for this symbol:
if (dlsym(RTLD_DEFAULT, "SLServiceTypeFacebook"))
NSLog(#"SLServiceTypeFacebook found via dlsym");
// But if you really just wanted to know is if SLRequest
// is available, you should really just do this:
if ([SLRequest class])
NSLog(#"SLRequest class is available");
Any of these should work as you were expecting in iOS5.1 versus iOS6.
just check with NSClassFromString if you can get the classes.. objC is all classes anyway :D
I have imported Reachable and followed the chosen anser on this thread: Reachability Guide for iOS 4 Everything looks good, apart from a yellow triangle saying "incomplete implementation". Then when I press run I get ten red errors coming from the Reachable.m file, saying things like "ARC forbids explicit message send of release', 'NSAutoReleasePool is unavailable in automatic counting reference mode' and 'Cast of C pointer of type 'void ': to objective-c pointer type 'Reachability' etc. and 'declaration of 'struct sockaddr_in' will not be visible outside of this function [3]' from the Reachable.h file. Any ideas? Maybe the Reachable files are out of date? I have no experience with using C data types etc. and whenever I have to import an extra implementation/header file things seem to go wrong :/.
Apple's Reachability sample code was last updated in 2010. It doesn't use ARC and contains code that is non-trivial to convert to ARC.
The solution is simple:
Set the -fno-objc-arc compiler flag for that file.