I assume this is the same for sqlite3.dll or sqlite3.lib, but if not, I am interested in sqlite3.o (mingw32).
How can I minimize the size of the library (compiling with -O3, since speed is my top concern, so different compiler optimizations is not an option)?
If I know there are parts of SQL I don't need in my program (like JOIN or ATTACH or triggers), can I remove support for them (this is for an embedded system and every byte counts, or at least every 100 bytes or so)?
What pre-processor options can I set to remove things like FTS or R-Tree support which I do not need? Do I set them at the command line or in the file?
Are there any other things easily removable that I might not need and might not even know they exist in order to remove them?
How about some of the C API? Most of it I never use.
Please look here. There's a chapter "Options to omit features". You'll find for example SQLITE_OMIT_ATTACH there.
But please note the warning there. It says
the SQLITE_OMIT_* compile-time options are usually untested and are
almost certainly untested in combination. Any or all of these options
may be removed from the code in future releases and without warning.
For any particular release, some of these options may cause
compile-time or run-time failures, particularly when used in
combination with other options.
Related
I want to use frama-c as an analyzer to check if a C source code have undefined behavior. I find the code provide by C-Reduce at here. However, some of flags in this script I can not find it in the new version of frama-c.
The flags I can not find list as follows:
-stop-at-first-alarm
-precise-unions
I can find other in frama-c's changelog on github
But anyway, I can not find some flags, even a little bit description.
I am worried about the flag "-precise-unions", because it seems like to check the union. While "-stop-at-first-alarm" seems to save the time.
And I find a code here, that code doesn't using any of the flags that changed. But is it correct?
I really have no idea.
Thanks for your kindness.
Option -stop-at-first-alarm has been replaced with the more general -eva-stop-at-nth-alarm 1. You can replace 1 with a higher number, if you wish. What it does is to stop the analysis after the nth alarm is emitted. If your goal is to have 0 alarms and to closely inspect each alarm, this option might save time. But, in general, it does not improve the efficiency of the analysis.
-precise-unions is a very old option which has been obsoleted in Frama-C Fluorine (2013). It is no longer needed. It does not affect the correctness of the analysis.
The Csmith driver script you mention is indeed using old options, but they do not affect the correctness. By default, without any options, Frama-C/Eva will warn about undefined behaviors in the code. If you want to be more strict than the C standard (e.g. forbid unsigned overflows), then you may need to add extra options, such as -warn-unsigned-overflow.
I would like to know Why we need to compile the program of progress 4GL? Really what is happening behind there? Why we are getting .r file after compiled the program? When we check the syntax if its correct then we will get one message box 'Syntax is correct' how its finding the errors and showing the messages.Any explanations welcome and appreciated.
Benefits of compiled r-code include:
Syntax checking
Faster execution (r-code executes faster)
Security (r-code is not "human readable" and tampering with it will likely be noticed)
Licensing (r-code runtime licenses are much less expensive)
For "how its finding the errors and showing the messages" -- at a high level it is like any compiler. It evaluates the provided source against a syntax tree and lets you know when you violate the rules. Compiler design and construction is a fairly advanced topic that probably isn't going to fit into a simple SO question -- but if you had something more specific that could stand on its own as a question someone might be able to help.
The short answer is that when you compile, you're translating your program to a language the machine understands. You're asking two different questions here, so let me give you a simple answer to the first: you don't NEED to compile if you're the only one using the program, for example. But in order to have your program optimized (since it's already at the machine language level) and guarantee no one is messing with your logic, we compile the code and usually don't allow regular users to access the source code.
The second question, how does the syntax checker work, I believe it would be better for you to Google and choose some articles to read about compilers. They're complex, but in a nutshell what they do is take what Progress expects as full, operational commands, and compare to what you do. For example, if you do a
Find first customer where customer.active = yes no-error.
Progress will check if customer is a table, if customer.active is a field in that table, if it's the logical type, since you are filtering if it is yes, and if your whole conditions can be translated to one single true or false Boolean value. It goes on to check if you specified a lock (and default to shared if you haven't, like in my example, which is a no-no, by the way), what happens if there are multiple records (since I said first, then get just the first one) and finally what happens if it fails. If you check the find statement, there are more options to customize it, and the compiler will simply compare your use of the statement to what Progress can have for it. And collect all errors if it can't. That's why sometimes compilers will give you generic messages. Since they don't know what you're trying to do, all they can do is tell you what's basically wrong with what you wrote.
Hope this helps you understand.
Some libraries, e.g. xml-rpc, directly use url-retrieve. I want them to instead use request.el, so that I can choose curl as my backend. Is there an easy shim-layer I can install?
I'm looking for something like curl-for-url, which transparently rebinds url-http with a compatible implementation. (curl-for-url itself doesn't actually work very well, though.)
You could do this using advice, but you will need to use the
ad-get-arg/ad-get-args functions to extract the arguments url-retrieve was
called with and determine how you want to process them and pass them to the
retrieve function. The one which will likely be problematic is the callback
function. However, provided you can setup the buffer with the downloaded
data in the same way, with the same name as url-retrieve, you should be able to
apply the callback manually after the call to request and you have setup the
buffers as necessary.
It will be a fair bit of work and you will need to dig deep into both the url.el
and request.el libraries. It is also likely to be a bit fragile.
One concern I would have is the use of monkey patching by request.el. From the
project page, it looks like this code has not been updated since Emacs version
25.1 and the current official emacs is 25.2. This is one of the problems with
monkey patching - you need to keep versions in sync to avoid version
incompatibility issues.
It also seems odd to me to have someone who has patches to fix known bugs if
those patches have not been applied to the mainstream version - especially when
there has been a more recent release of the mainstream version.
The first thing I would do is upgrade to emacs 25.2 and then determine if using
request.el is as justified. I would also verify the problems you experience are
actually due to url-retrieve or are perhaps due to callbacks being passed to
that function. If it is a problem with the callbacks, you may be better off
using advice to fix those callbacks rather than replace the underlying
problems.
If you only have issues in some situations where url-retrieve is used, it may
also be easier to go up one level and look at the things which are using it and
perhaps use something like advice to replace the call to url-retrieve with
request at that level.
Someone might be able to provide more specific recommendations if you provide
more detail on the precise reasons you cannot or do not want to use the
url.el library.
How are we actually supposed to include our OpenCL code in our C projects?
We can't possibly be supposed to ship our .cl files along with our executable for the executable to find them and load them at runtime, because that's stupid, right?
We can't be supposed to use some stringify macro because a) that's apparently not portable/leads to undefined behaviour and b) it all breaks down if you use commas not enclosed in brackets like when defining many variables of the same type, I've spent an hour here looking for a solution to that and there doesn't seem to be one that actually works and c) that's kind of stupid.
Are we expected to write our code into C string literals like "int x, y;\n" "float4 p;\n"? Because I'm not doing that. Are we supposed to do a C include-style hexdump of our .cl files? That seems inconvenient. What are we actually supposed to do?
It's bad enough that all these approaches basically mean that you have to ship your program with your OpenCL code essentially open sourced when your OpenCL code is probably the last thing you want open sourced, on top of it it seems every OpenCL project I've seen uses one of the approaches listed above, it just doesn't seem right at all, it's like the people who made OpenCL forgot about something.
This thread: OpenCL bytecode running on another card mentions SPIR, a "platform-portable intermediate representation for OpenCL device programs". Other than that, you are basically restrained to the options you already mentioned.
Personally, I began to use C++11 raw string literals to get rid of my nasty stringify-macros. Don't know if C++ is an option for you, however.
Concerning your rejection of the "ship our .cl files along with our executable" approach: I don't see why this is inherently stupid -- the CL "shaders" are an application resource like all other separate files beside the executable, and thus are part of the "application bundle". It's perfectly reasonable to have such kind of files, and each operating system has its way to deal with it (in win32, the program directory is the bundle https://blogs.msdn.microsoft.com/oldnewthing/20110620-00/?p=10393 , OSX has its own bundle concept, etc...).
Now, if you are worried about other people peeking into your OpenCL code, you can still apply some obfuscation methods (e.g. encrypt your .cl-files by a key which is more or less cleverly hidden in your executable).
[edit/sidenote]: We could also investigate how other companies deal with this issue in the context of, for example, OpenGL/Direct3D shaders. In my limited experience, gaming companies tend to dump their shaders in text form somewhere in their application directory, for all to see (and even to tamper with). So in the gaming world at least, there is no great deal of secrecy in that respect... Wonder what adobe or CAD software companies do in their professional software.
How can I package my Java application into an executable jar that cannot be decompiled (for example , by Jadclipse)?
You can't. If the JRE can run it, an application can de-compile it.
The best you can hope for is to make it very hard to read (replace all symbols with combinations of 'l' and '1' and 'O' and '0', put in lots of useless code and so on). You'd be surprised how unreadable you can make code, even with a relatively dumb translation tool.
This is called obfuscation and, while not perfect, it's sometimes adequate.
Remember, you can't stop the determined hacker any more than the determined burglar. What you're trying to do is make things very hard for the casual attacker. When presented with the symbols O001l1ll10O, O001llll10O, OO01l1ll10O, O0Ol11ll10O and O001l1ll1OO, and code that doesn't seem to do anything useful, most people will just give up.
First you can't avoid people reverse engineering your code. The JVM bytecode has to be plain to be executed and there are several programs to reverse engineer it (same applies to .NET CLR). You can only make it more and more difficult to raise the barrier (i.e. cost) to see and understand your code.
Usual way is to obfuscate the source with some tool. Classes, methods and fields are renamed throughout the codebase, even with invalid identifiers if you choose to, making the code next to impossible to comprehend. I had good results with JODE in the past. After obfuscating use a decompiler to see what your code looks like...
Next to obfuscation you can encrypt your class files (all but a small starter class) with some method and use a custom class loader to decrypt them. Unfortunately the class loader class can't be encrypted itself, so people might figure out the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code got smaller. Again this does not prevent people from seeing your code, just makes it harder for the casual attacker.
You could also try to convert the Java application to some windows EXE which would hide the clue that it's Java at all (to some degree) or really compile into machine code, depending on your need of JVM features. (I did not try this.)
GCJ is a free tool that can compile to either bytecode or native code. Keeping in mind, that does sort of defeat the purpose of Java.
A little late I know, but the answer is no.
Even if you write in C and compile to native code, there are dissasemblers / debuggers which will allow people to step through your code. Granted - debugging optimized code without symbolic information is a pain - but it can be done, I've had to do it on occasion.
There are steps that you can take to make this harder - e.g. on windows you can call the IsDebuggerPresent API in a loop to see if somebody is debugging your process, and if yes and it is a release build - terminate the process. Of course a sufficiently determined attacker could intercept your call to IsDebuggerPresent and always return false.
There are a whole variety of techniques that have cropped up - people who want to protect something and people who are out to crack it wide open, it is a veritable arms race! Once you go down this path - you will have to constantly keep updating/upgrading your defenses, there is no stopping.
This not my practical solution but , here i think good collection or resource and tutorials for making it happen to highest level of satisfaction.
A suggestion from this website (oracle community)
(clean way), Obfuscate your code, there are many open source and free
obfuscator tools, here is a simple list of them : [Open source
obfuscators list] .
These tools make your code unreadable( though still you can decompile
it) by changing names. this is the most common way to protect your
code.
2.(Not so clean way) If you have a specific target platform (like windows) or you can have different versions for different platforms,
you can write a sophisticated part of your algorithms in a low level
language like C (which is very hard to decompile and understand) and
use it as a native library in you java application. it is not clean,
because many of us use java for it's cross-platform abilities, and
this method fades that ability.
and this one below a step by step follow :
ProtectYourJavaCode
Enjoy!
Keep your solutions added we need this more.