I am fairly new to using gdb debugger and so coming across the code being displayed when I ran gdb left me having no use for the debugger. I am unfamiliar with the code being displayed but a did a little research and I assume I accidentally opened up a "thread"? It's hard to explain something I do not understand but I will link a picture explaining what I am talking about. Basically I want to revert back to the "basic" display of my actual code and not this: displayed by the debugger
Your program called one of scanf family of functions, with a NULL stream.
Usually this happens when you don't check for errors. For example:
FILE *fp = fopen("/file/which/does/not/exist", "r");
char ch;
fscanf(fp, "%c", &ch); /* BUG: should check fp!=NULL first. */
You should always check return value from any function that may fail.
You can see which code called into the fscanf with GDB where command.
Related
After last week's updated to Xcode 8.3, in a C/C++ program the output from a printf statement no longer appears on the screen without a newline. Thus I can't prompt for the user to enter a number, and have them type in that number on the same line following the input prompt.
Neither flushing the output buffer [fflush(stdout) or cout << endl] nor setting the output buffer to NULL [setbuf(stdout, NULL)] addresses this problem, but rather is a question specifically about Xcode 8.3 seemingly being broken.
With the scanf commented out, the output of the program below is:
Enter a value for x: Value of x is: 0
With the scanf in place, the output from the first printf never shows up. If you go ahead and type in a value and press enter, only then does it show up. Output is:
3
Enter a value for x: Value of x is: 3
Full test program is here:
#include <iostream>
using namespace std;
int main() {
int x=0;
printf("Enter a value for x: ");
//scanf("%d", &x);
printf("Value of x is: %d\n", x);
return 0;
}
My work-around has been to revert back to Xcode 8.2.1, downloaded from developer.apple.com/xcode/downloads/
8.3.2 was announced last night and addresses this supposedly:
It is standard behavior in C for stdout to be flushed when an input function is called, such as scanf(), regardless of whether a newline was output prior to the call or not. This ensures that all appropriate output is displayed before the input operation takes place. Therefore, the update might have broken something in Xcode. Although I'm not currently sure what the exact nature of the problem is, a (temporary) workaround is to run your application on the command line. This has worked for my projects. It also reveals that this problem is with the Xcode output window, and not the compiler or something else.
In response to tell's comment: no, flushing stdout does not correct the issue within Xcode. This implies even more strongly to me that the issue is definitely in the Xcode interface itself. When running the application from the command line, calls to fflush() work as expected.
Also, printing to stderr makes no difference from within Xcode. Basically, stdout should be flushed in this case without appealing to stderr or any other gimmicks because the OP is calling scanf(). It works perfectly from the command line... just not in the Xcode output window.
And please note this this question is not a duplicate: it has nothing to do with anyone's misunderstanding of how C input and output work, and everything to do with the fact that a recent update to Xcode broke something.
EDIT:
Thanks, joe_04_04. The update certainly seems to have fixed the problem.
I have a little confused about the result of two slightly different piece of code like this:
FILE* file=fopen("test.txt","w");
char buffer[6]="hello";
char arr[6]="haloo";
//setbuf(file,buffer);
fputs(arr,file);
//fflush(file);
As you can see I firstly commented out two line of code. So the buffer would not be flushed until I close the program, at which time the file stream will be closed too. And then, as what I expect, the program would write the haloo to the test.txt as soon as I close the program. And the same things happened When I don't commented out those two lines. Like this:
setbuf(file,buffer);
fputs(arr,file);
fflush(file);
But, when I only commented out only the flush(file) line of code, like this:
setbuf(file,buffer);
fputs(arr,file);
//fflushed(file);
strange thing happen. I got things like 2800 c579 7a in my test.txt when I close my program.
And then I try to change the buffer a little bit, to something like this:
char buffer[5]="hell"; //change the contents a little bit
char arr[5]="halo"; // also change a little bit
setbuf(file,buffer);
fputs(arr,file);
//fflush(file);
Then I got 00c5 797a in my text.txt.
So I wonder if this is any undefined behavior or default pattern that I don't know.
I think you want to terminate your buffer with a '\0'. Check that out.
If you are not calling fclose, there might be an undefined behaviour problem because of setbuf, see http://man7.org/linux/man-pages/man3/setbuf.3.html.
Check adding a fclose at the end of the program, this will make sure the fflush is enforced and the stream is cleanly closed, while at the same time avoiding the above mentioned bug.
I need to decompile a windows program which the source code was lost for a long time.
I am using boomerang in Windows 7 for this. However, it looks broken, gives this message and quits:
Could not open dynamic loader library Win32BinaryFile.dll (error #998)
Googling about it gives no useful results. Looking in the boomerang source code, it is apparently coming from this:
00137 hModule = LoadLibraryA(libName.c_str());
00138 if(hModule == NULL) {
00139 int err = GetLastError();
00140 fprintf( stderr, "Could not open dynamic loader library %s (error #%d)\n", libName.c_str(), err);
00141 fclose(f);
00142 return NULL;
00143 }
I.e. LoadLibraryA is failing with the status 998.
What could I do to fix that?
Edit, four hours later:
The program that I want to decompile is a work that me and a friend implemented in 2005. The source just gone in the mean time without we seeing that. Now, in 2013, when we searched it, nothing was found. In retrospect, it was probably lost in 2008 or in 2010, two occasions where my computer hardware crashed and I needed to get a new computer (and lost a lot of data with that). We had several backups scattered in several places, but after an exhaustive search, I found nothing.
I know that since boomerang is open source, I could just get its source code and hack it around. However, that sort of task is not what I originally intended to do, since the focus is just to decompile my program and I guess that I am missing something simple, since it can't load the DLL while it is clearly there.
I don't need the exact code back, just a sketch of what were the exact details of the algorithm that were implemented. Having that, I can rewrite the rest again.
How can I give commands to Linux console (Ubuntu) from my c++ program, and assign a value, which my command tells, to string variable? Please, give me an example, in which program gives simple command "uname -a" to console and writes result.
Sorry for my bad English, I know it very little. I would be very happy, if someone will write his answer in Russian (if it allowed) . I was looking for the answer to my question in Russian resources, but found nothing, you're my last hope.
The command you need is popen. You can get information about it by typing man popen into your shell; if your Linux distribution runs its Russian translation, it should display the information about it in Russian.
Basically, popen just opens a "file" (stream), with which you can work just like with a regular file. Here's an example of how it could be used:
#include <stdio.h>
int main()
{
FILE *f;
char stuff[100];
f = popen("uname -a", "r");
fgets(stuff, 100, f);
printf("%s", stuff);
pclose(f);
}
The code above doesn't have any error handling; you should insert the appropriate checks after you read and understand the complete manual page (rus).
Look for Russian language resources that explain the popen(3) library routine. You will need to use popen to launch the command, then read the pipe to obtain the output.
I am working on a simple application written in C. I am working in a Unix environment.
My application is doing some simple I/O. I use printf to prompt the user for some input and then use scanf to get that input.
The problem is, I don't know how to tell my application that I am ready to proceed after entering in a value. Typing 'enter' provides a newline '\n' which makes sense. Control-d does allow scanf to capture my input but seems to ignore any subsequent scanf instructions.
Can someone help me out?
printf("Enter name\n");
scanf("%s",input);
printf("%s",input);
printf("enter more junk\n")
scanf("%s",morestuff); /* cntrl+d skips this*/
Check the return value from scanf(). Once it has gotten EOF (as a result of you typing control-D), it will fail each time until you clear the error.
Be cautious about using scanf(); I find it too hard to use in the real world because it does not give me the control over error handling that I think I need. I recommend using fgets() or an equivalent to read lines of data, and then use sscanf() - a much more civilized function - to parse the data.
See also a loosely related question: SO 3591642.
[EDIT: This answer is incorrect, as I stated below, I'm learning as well]
Have you tried CTRL-Z?
That sends EOF to scanf, which, according to its man page, should make scanf move to the next field. As you've entered only a string as the input format, that should terminate the scanf.
I can't test this right now, but you can give it a shot.
Man page is here:
http://www.slac.stanford.edu/comp/unix/package/rtems/doc/html/libc/libc.info.scanf.html