| Assignment • FAQ • Development Guide • Code • Checklist • |
Question:
Why am I seeing "garbage" in the terminal's output when I run my program?
Answer:
You are most likely printing out ASCII values (characters) of blocks of memory that you did not allocate. A block of memory will have whatever value was last written to it, and therefore, have "strange" values if you did not purposely write to the memory yourself. This typically happens when you attempt to print out the values of an array but kept printing out values past the length of the array.
Question:
After I run my program and the professor's program side by side with all the exact same inputs, and press ^D at the end, the first few messages (the address, I'm assuming) are all different,
The value of ap is: 3220980308
And in hexidecimal is: 0x00000000BFFC4254
The value of app is: 3220980304
And in hexidecimal is: 0x00000000BFFC4250
The value of apx is: 3220980308
And in hexidecimal is: 0x00000000BFFC4254
The value of ap + 1 is: 3220980312
And in hexidecimal is: 0x00000000BFFC4258
The address of array[0] is: 3220980308
The address of array[1] is: 3220980312
But the second half are all identical to the professor's output.
Is this normal behavior? I got confused since this is a little different from the Question in the homework packet.
Answer:
Yes, that is normal. The addresses that your program uses and the addresses that my program uses can be different because the code to implement each executable is not identical.
Question:
I'm a bit confused as to how clrbuf should operate. I understand that if the incoming character is the newline char that it should do nothing, but if it isn't then what should clrbuf do? The description in the code says to call fgetc multiple times to clear the stream, which works.. but I don't know if it's implied whether I should just throw away what's in the buffer or send it immediately in line format to stdout..
Answer:
The most helpful example for this is getaline(). When you implement getaline(), you only accept MAXLENGTH-1 number of characters. However, if the user enters more than MAXLENGTH-1 number of characters, those characters that are not cleared from stdin buffer are still in the buffer. This means that these leftover characters in stdin buffer need to be cleared in some way. The only efficient way for us to do this is by calling clrbuf(), because clrbuf() will go through stdin buffer and just throw away (meaning not doing anything with the character retrieved from stdin) the input.
If I enter
abcdefghijklmnopqrstuvwxyzasdfqeoirfjzvbnlkajsdlfkjoqiehkaljvklnkajdhfakjfhoewifrualdkfjk
as input. stdin will contain all of these chars + newline char implicitly in the end
However, our getaline method will accept only 79 characters. That means,
abcdefghijklmnopqrstuvwxyzasdfqeoirfjzvbnlkajsdlfkjoqiehkaljvklnkajdhfakjfhoewifrualdkfjk
only the underlined chars above will be read from stdin by using fgetc. The rest of the string is still existing in side the stdin, though. Hence, we call clrbuf to clear the rest of the string in stdin. If you don't do this, you will be reading those "garbage" string next time when you call fgetc(stdin).
Question:
After you press ^D to terminate program, a series of lines are displayed. The lines of concern are the memory addresses printed, and the hexidecimal for the memory addresses.
When I run my program, I get junk displayed for the memory address, and hexidecimal for the memory address.
This is the display I get.
The value of ap is: .*(,,0-+.
And in hexidecimal is: 0x0000000012345678
The value of app is: .*(,,0-+*
And in hexidecimal is: 0x0000000012345678
The value of apx is: .*(,,0-+.
And in hexidecimal is: 0x0000000012345678
The value of ap + 1 is: .*(,,0-,(
And in hexidecimal is: 0x0000000012345678
The address of array[0] is: .*(,,0-+.
The address of array[1] is: .*(,,0-,(
Answer:
For the decimal values, this is as expected, as was discussed in class. The addresses are so large, that when interpreted as a signed number, they are negative. Since decout only prints positive values, these numbers are not appropriate. During your program testing, we are not going to pass negative numbers to decout.
However for hexout, this is really a shorthand way to display all the bits in a word. As such, you should interpret the parameter as an "unsigned long". Additionally, in your logic, you should make sure that your quotient variable is also unsigned. That should resolve your problem.
If you pass in an unsigned value that has the most significant bit set to 1, when you assign that value to a signed variable, the magnitude of that number changes dramatically although the bit pattern remains the name. As such, any quotients and remainders that you get will be very different.
For example, the value of 0xFFFFFFFFFFFFFFFF is both -1 (when signed) and (2 to the 64) minus one (when unsigned). Obviously, the quotient and the remainder of these numbers divided by 16 will result in very differing results depending upon whether you declared your variables as signed or unsigned.
Question:
This does not occur in Linux, it works perfectly there. Is this an error in my code?
Answer:
Yes, there is an error in your code.
Your "writeline" method is the method that displays the string that the user enters. The "writeline" method stops the string display when it prints a NULL character. If you get extra output that is not expected, then my guess is that you are not explicitly storing a NULL character at the end of the string that you create within your "getaline" method. That NULL character needs to be there so that writeline knows when to stop.
The reason that it appears to work on one computer with one compiler and not on another is that on one computer you HAPPEN TO HAVE a NULL character at the end of your array that getaline uses to store the string. If one computer uses a blank array, then it's filled with NULL characters before you store any of the user's input. Getaline overwrites the first characters with input from the user, and the rest of the characters remain NULL. Therefore, the result is that you got lucky that here just happens to be a NULL character at the end of user input, resulting in what appears as correct behavior. Then, when you transfer your code to a machine what did not happen to use a NULL filled array, your method no longer works.
This is a great lesson about the perplexing problems that occur with software is ported from one machine to another machine. These kinds of errors are very frustration to resolve. Only your knowledge of what's going on behind the scenes give you the insights into how such behavior can happen and how to resolve it.
I'm glad that you ran into this problem so that the class could all benefit from its resolution.
Question:
some times i get this warning "control reaches end of non-void method" under the last { of a method? ? i am not sure why this happens?
Answer:
A non-void method is a method that is declared to return a value. Control reaching the end of a method means that you are all done executing that method and will return. Therefore, control reaches the end of a non-void method means that you are finishing executing of a method that should return a value but you aren't sending a value back to the caller.
If your method returns "int", then this error means that you can leave the method without returning that int that you declared you were going to return.
Question:
The sample program always says that the string entered is 79 characters no matter what length string (i.e, 150 characers), so we are not to go to eighty?
Answer:
If you only have allocated/declared space for 80 chars, that means you can only store 79 real characters since you need the last space to store the NULL character.
Question:
I was running the sample test, and this seemed pretty obvious, but just wanted to clearify it. When it says, Please enter a decimal number:, Do you really mean an integer (ie, not floating point)?
Answer:
Yes, a decimal number is intented to be a decimal whole number in base 10.
| Assignment • FAQ • Development Guide • Code • Checklist • |