确定 const char* 是字符串文字还是变量

Question

Is there any simple method to detect, if the parameter passed to a function(const char *argument) was a constant literal or a variable?

I'm trying to fix errors in some code, which is filled with IsBadWritePtr calls, which throw access violation exceptions if the parameter was a constant literal.

This was a terrible design stupidity but now I'm not allowed to change the awkward behavior.

Answer 1

You can add a different overload that will be a better match for string literals. This is not really science but just heuristics:

void f(const char* p); // potential literal
void f(char *p);       // pointer to non-const

Another idea would be taking advantage that literals are really arrays :

template <int N>
void f(const char (&_)[N]); // potential literal 

Note that they don't quite detect literal vs. not literal , but rather some of the other features. const char* p = createANewString(); f(p); will resolve to f(const char*) , and const char x[] = { 'A', 'b', 'c', '\\0' }; will resolve to the template. Neither of them are literals , but you probably don't want to modify either.

Once you make that change, is should be simple to find out where each of the overloads is called.

This all works on the premise that the main function should not take the argument as const char* if it modifies it internally, and that the issue you are facing is because for backwards compatibility your compiler is allowing the call to a function that takes a pointer to non-const with a literal...

Answer 2

I don't think there is an way to detect that not at-least without using some hackery.
Since the interface takes a const char * the responsibility of the function is to not modify the passed string anyways. You need to modify the implementation because it is simply incorrect.

Answer 3

VirtualQuery can be used to detect if the address is writable, read-only, or inaccessible. Examine the State and Protect members of the returned MEMORY_BASIC_INFORMATION structure to see if the memory is accessible and has the access you need.

Answer 4

One VERY hackish way would involve checking if the pointer is in the .rdata segment.

Use dumpbin /headers after the build to retrieve the offset and length of the .rdata section, or parse the PE headers yourself. naturally, this is toolchain specific and generally a bad idea. Also, if the code needs to interoperate with DLLs, you'd have to check several executables and several .rdata segments.