I borrowed some code from dsimple.c that makes a call to XdisplayName. gcc tells me it is an 'undefined reference'. It seems to be a legitimate call, but I cannot find the header file where it is declared.
On my system it is X11/Xlib.h. Are you sure you didn't mistype it? (your post says 'XdisplayName', although the title is correct).
Related
I'm trying to get the call stacks of Ruby interpreter when it gets executed. For example, I have some ruby code in foo.rb and when I execute it with some options (if any to get the call stack) by $ruby foo.rb, then I would like to get which functions of interpreter get executed.
I found this (https://programmer.help/blogs/ruby-2.x-source-code-learning-an-overview-of-interpreters.html) nice article related to my questions and provides some idea of how I should approach, but I'm not quite sure how I should do it.
Basically, the article is saying that "Open OPT_CALL_THREADED_CODE switch in vm_opts.h header file when compiling Ruby
ruby_run_node call stack" to get the call stack, but I don't really get what does it mean by "Open OPT_CALL_THREADED_CODE".
I did look at the vm_opts.h, but it does not tell much.
This issue is a very specific topic, but if anyone has any idea how I can get the call stack in anyways or with the method the article is suggesting, please please help me out here.
Thank you for all your help!
I was unable to find any hint of the exact meaning of the SE_ERR_ASSOCINCOMPLETE ShellExecute return value.
I know that MSDN says "The file name association is incomplete or invalid", but what exactly does that mean? In what situations can it occur?
The best information on this can be found in the documentation. Which supplies the text:
The file name association is incomplete or invalid.
Which is what you've found out. To be honest it seems reasonably clear what it means, specifically that there is something wrong with the file association that has prevented the function from completing.
As to what SE_ERR_ASSOCINCOMPLETE means in full gory detail, that is an exhaustive list of all possible failure modes, you'll likely never find out. This is a deprecated function that exists solely to maintain backwards compatibility. The chances of Microsoft offering more insight into its works are vanishingly small.
The smart play here is not to call ShellExecute. Its error handling is crippled. Instead use ShellExecuteEx. When that fails, use GetLastError to get a Win32 error code.
Read more about that in Raymond Chen's article, Why does ShellExecute return SE_ERR_ACCESSDENIED for nearly everything? And then ask yourself what is the point of trying to gain a full understanding of the error codes that this function returns when most of the time you'll get SE_ERR_ACCESSDENIED.
I remember seeing somewhere that you can specify which dll to get the address of symbols so that one can use that variable in the watch window. I can't for the life of me remember where I saw this. The best that I can come up with is Format Specifiers in C++.
The reason I want this is so that I can see the visibility status of a window and MSVS keeps saying that identifier "IsWindowVisible" is undefined.
I was trying to use something like the following in the watch window:
::IsWindowVisible(m_hWnd),user32.dll
Using:
this->IsWindowVisible()
results in Function CWnd::IsWindowVisible has no address, possibly due to compiler optimizations. which is why I'm trying to use the win32 call. Ideas?
http://msdn.microsoft.com/en-nz/library/y2t7ahxk.aspx
Haven't tried it, but it seems to me that IsWindowVisible(m_hWnd) should work, or maybe IsWindowVisible(this->m_hWnd).
I want to do something similar to how, in GCC, you can do syntax checking on printf-style calls (to make sure that the argument list is actually correct for the call).
I have some functions that take a variable number of parameters. Rather than enforce what parameters are sent, I need to ensure that the last parameter passed is a NULL, regardless of how many parameters are passed-in.
Is there a way to get GCC to do this type of syntax check during compile time?
You probably want the sentinel function attribute, so declare your function like
void foo(int,double,...) __attribute__((sentinel));
You might consider customizing your GCC with a plugin or a MELT extension to typecheck more precisely your variadic functions. That is, you could extend GCC with your own attributes which would do more precise checks (or simply make additional checks based on the names of your functions).
The ex06/ example of melt-examples is doing a similar check for the jansson library; unfortunately that example is incomplete today October 18th 2012, I am still working on it.
In addition, you could define a variadic macro to call such a function by always adding a NULL e.g. something like:
#define FOO(N,D,...) foo((N),(D),##__V_ARGS__,NULL)
Then by coding FOO(i+3,3.14,"a") you'll get foo((i+3),(3.14),"a",NULL) so you are sure that a NULL is appended.
Basile Starynkevitch is right, go with a function attribute. There are a ton of other useful function attributes, like being able to tell the compiler "If the caller doesn't check the return value of this function, it's an error."
You may also want to see if splint can check for you, but I don't think so. I think it would have stuck in my memory.
If you haven't read over this page of GCC compiler flags, do that, too. There are a ton of handy checks in there. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
I'm using the DyninstAPI (namely, the SymtabAPI component) to rewrite the symbol tables in binaries. I'm using the following methods to do so:
data_region->setPtrToRawData((void*) new_raw, data_region->getRegionSize())
The method returns successfully, I check my error codes, and I even re-read the data section which has successfully been replaced. The problem is that the original binary isn't rewritten with the new raw .data section, and the original raw .data section persists.
I've scoured the manual to see if there is some sort of commit function but none is documented and nothing of the sort is mentioned in the examples. EDIT: I just read through some of the source code for the Region class, and it looks like I'm essentially doing what patchData does (in case that is the method I should be using).
Suggestions?
The programming manuals are available at http://www.paradyn.org/html/manuals.html.
P.S. hopefully a more reputable user can add the tags DyninstAPI and SymtabAPI for me.
After consulting with the developers, they alerted me that the function I needed to call was emit and the syntax I ended up using was:
symtab_obj->emit("new_binary.out");
Thanks Drew!