The static code analysis tool cppcheck reported a severe error in the code below: I don't know what is the problem.
#define NUM_UPDATE_COUNT 3
#define MAX_NUM_CH_1LINE 27
wchar_t m_cCnt_Buf[NUM_UPDATE_COUNT][MAX_NUM_CH_1LINE];
Init_PushPt();
memset((char *)&m_cCnt_Buf[1], 0x20, sizeof(m_cCnt_Buf[1])); /* Buffer is accessed out of bounds: m_cCnt_Buf */
memset((char *)&m_cCnt_Buf[2], 0x20, sizeof(m_cCnt_Buf[2])); /* Buffer is accessed out of bounds: m_cCnt_Buf */
m_cCnt_Buf[1][2] = '0';
m_cCnt_Buf[2][8] = '0';
There doesn't seem to be anything wrong with the code above. Any ideas why these get picked up and how fix this? Thank you in advance.
I am a Cppcheck developer.
Interesting. It looks like a FP to me. However I fail to reproduce this FP with Cppcheck.
Related
I recently came around this article (http://www.splinter.com.au/2014/09/16/storing-secret-keys/) that talks about obfuscation on iOS.
I quote:
To somewhat mitigate the risk of crackers attacking your app with a debugger (LLDB or GDB), you can insert some code in your app that makes it crash as soon as it detects a debugger attached. The iTunes app uses this technique, you can read about it here.
This is achieved by calling the following code in main()
#import <dlfcn.h>
#import <sys/types.h>
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#if !defined(PT_DENY_ATTACH)
#define PT_DENY_ATTACH 31
#endif // !defined(PT_DENY_ATTACH)
void disable_gdb() {
void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
ptrace_ptr_t ptrace_ptr = dlsym(handle, "ptrace");
ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
dlclose(handle);
}
I understand that these lines of code make the debugger crash when attached to the process but how does it achieve this behaviour?
Also, would that be impairing the stability of the app in any way?
Seems like a similar question on OS X has already been answered here: Implementing the PT_DENY_ATTACH anti-piracy code.
TL;DR - As Jim Ingham points out in the comments, it's a waste of time.
I am using VerificationController.m provided by Raywenderlich for validating receipts for in ap purchase. It is working fine for XCode5 but in XCode6 it is giving number of errors. probably due to C++ code like:
Missing Code for Method declaration
#end must appear in objective-c
context Conflicting types for 'checkReiptSecurity'
can anyone tell me what is needed to be done ?
Edit : Here are errors screenshot
Have you fixed this? I was running in to the exact same problem so I'll leave my fix here for anyone that comes looking. It turns out in newer versions of Xcode you aren't allowed to put C/C++ code in objective-C context anymore. So I moved the declarations for unsigned int iTS_intermediate_der_len, unsigned char iTS_intermediate_der[], char* base64_encode(const void* buf, size_t size), and void * base64_decode(const char* s, size_t * data_len) to the top of the file, above the #implementation tag.
Have you downloaded sample code? I have downloaded sample code and its working fine at my side. It seems that you have missed or added an extra braket } or { in your code.
May be this happened when you was trying to comment this code [UIDevice currentDevice].uniqueIdentifier; because originally this line produce an error.
Is it possible in iOS to detect the current processor of the device.
The project I am working on requires, programmatically, to check if the processor is ArmV7 or ArmV7s.
I don't know for certain that this will provide the information you'd like but I would try sysctl:
int32_t value = 0;
size_t length = sizeof(value);
sysctlbyname("hw.cpusubtype", &value, &length, NULL, 0);
The values for subtype are in mach/machine.h.
/*
* ARM subtypes
*/
#define CPU_SUBTYPE_ARM_ALL ((cpu_subtype_t) 0)
#define CPU_SUBTYPE_ARM_V4T ((cpu_subtype_t) 5)
#define CPU_SUBTYPE_ARM_V6 ((cpu_subtype_t) 6)
#define CPU_SUBTYPE_ARM_V5TEJ ((cpu_subtype_t) 7)
#define CPU_SUBTYPE_ARM_XSCALE ((cpu_subtype_t) 8)
#define CPU_SUBTYPE_ARM_V7 ((cpu_subtype_t) 9)
#define CPU_SUBTYPE_ARM_V7F ((cpu_subtype_t) 10) /* Cortex A9 */
#define CPU_SUBTYPE_ARM_V7K ((cpu_subtype_t) 12) /* Kirkwood40 */
I'm not aware of any API to check this, but you could perhaps write one yourself by providing v7 and v7s assembler implementations for the same symbol that simply return true or false as required.
Assuming that the v7s implementation will be used if and only if the processor supports v7s, it should work.
This way:
sysctlbyname("hw.cpusubtype", &value, &length, NULL, 0);
is good, but there are more easy way:
#include <mach-o/ldsyms.h>
int processorType = _mh_execute_header.cputype;
int processorSubtype = _mh_execute_header.cpusubtype;
Although, it shows you which cpu used in compile time for current code..
You don't.
That is, it is not advisable to programmatically detect ARM architecture version support at runtime on iOS. This is the answer I got from an Apple engineer when I specifically asked this question, and given the pitfalls (e.g. what do you do when you get an unexpected value?), I can believe them.
(yes, sometimes the correct answer to an "How do I?" question is "You don't.")
In clang, is there a way to enable bounds checking for [] access to std::vectors and other STL containers, preferably when building in debug mode only?
I just spent hours hunting down a subtle bug that turned out to be caused by us accessing past the end of a std::vector. It doesn't need to do anything clever when it detects the error, just trap in the debugger so that I can find out where it happened and fix it in the code.
Is there a way to do this other than "create your own type that inherits from std::vector", which I'd like to avoid?
(I'm using clang version 3.1 if that makes a difference.)
libstdc++ has a mature debug mode using -D_GLIBCXX_DEBUG.
libc++ also has a debug mode using -D_LIBCPP_DEBUG but as we can see this mailing list discussion: Status of the libc++ debug mode it is incomplete:
| My understanding is that this work was never completed and it's
probably broken/incomplete.
That is correct.
It’s on my list of things to fix/implement, but it’s not something that I will get to anytime soon.
It does seem to work for std::vector on 3.4 and up see it live, give the following program:
#include <vector>
#include <iostream>
int main()
{
std::vector<int> v = {0,1,2,3} ;
std::cout << v[-1] << std::endl ;
}
it generates the following error:
vector[] index out of bounds
Aborted
If you're using Linux or OS X you should look into the address sanitizer:
http://clang.llvm.org/docs/AddressSanitizer.html
It introduces a 2x slowdown, but does a bunch of memory checking and may catch your bug.
Another amazing tool that has saved me countless times is valgrind. If you can run with valgrind it will catch a ton of memory bugs and leaks.
#define _GLIBCXX_DEBUG
This enables all kinds of inline checking (see vector and debug/vector)
Hey there,
I have the following piece of code:
#if USE_CONST == 1
__constant__ double PNT[ SIZE ];
#else
__device__ double *PNT;
#endif
and a bit later I have:
#if USE_CONST == 0
cudaMalloc((void **)&PNT, sizeof(double)*SIZE);
cudaMemcpy(PNT, point, sizeof(double)*SIZE, cudaMemcpyHostToDevice);
#else
cudaMemcpyToSymbol(PNT, point, sizeof(double)*SIZE);
#endif
whereas point is somewhere defined in the code before. When working with USE_CONST=1 everything works as expected, but when working without it, than it doesn't. I access the array in my kernel-function via
PNT[ index ]
Where's the problem between the both variants?
Thanks!
The correct usage of cudaMemcpyToSymbol prior to CUDA 4.0 is:
cudaMemcpyToSymbol("PNT", point, sizeof(double)*SIZE)
or alternatively:
double *cpnt;
cudaGetSymbolAddress((void **)&cpnt, "PNT");
cudaMemcpy(cpnt, point, sizeof(double)*SIZE, cudaMemcpyHostToDevice);
which might be a bit faster if you are planning to access the symbol from the host API more than once.
EDIT: misunderstood the question. For the global memory version, do something similar to the second version for constant memory
double *gpnt;
cudaGetSymbolAddress((void **)&gpnt, "PNT");
cudaMemcpy(gpnt, point, sizeof(double)*SIZE. cudaMemcpyHostToDevice););
Although this is an old question I add this for future googlers:
The problem is here:
cudaMalloc((void **)&PNT, sizeof(double)*SIZE);
cudaMemcpy(PNT, point, sizeof(double)*SIZE, cudaMemcpyHostToDevice);
The cudaMalloc writes to the host version of PNT which is actually a device variable that must not be accessed from host. So correct would be to allocate memory, copy the address to the device symbol and copy the memory to the the memory pointed to by that symbol:
void* memPtr;
cudaMalloc(&memPtr, sizeof(double)*SIZE);
cudaMemcpyToSymbol(PNT, &memPtr, sizeof(memPtr));
// In other places you'll need an additional:
// cudaMemcpyFromSymbol(&memPtr, PNT, sizeof(memPtr));
cudaMemcpy(memPtr, point, sizeof(double)*SIZE, cudaMemcpyHostToDevice);
Easier would be:
#if USE_CONST == 1
__constant__ double PNT[ SIZE ];
#else
__device__ double PNT[ SIZE ];
#endif
// No #if required anymore:
cudaMemcpyToSymbol(PNT, point, sizeof(double)*SIZE);