It may be hard for you to figure out the cause of the problem assuming that you just finished week 2. The problem deals with concepts like local variables, scope, stack, etc.
You may probably know about local variables and scope and you'll get exposed to the rest as you proceed with the course. I'll try to simplify things as much as I can. If you feel like ...
I just found a subtle error in the check function. The allocated size for the string is wrong. It's should've been word_copy[n + 1] instead of word_copy[LENGTH]. Thank you for your input though. I'm actually surprised that my program worked in the other scenarios.
The problem is that the tree isn't being freed. You could add a printf statement inside the unload function's loop to show it.
The cause is interesting, it leads to unpredictable results in a full scale run. Sometimes it will work, sometimes it might not.
I'll give you a big hint. Have you checked the hash values being generated? Also, what is the ASCII ...
Have you looked at the actual hex data of the file instead of the image? When looking at the image, the header data (assuming it's correct) will only allow the display of the specified amount of data in the image. Any extra data at the end of the image will not be displayed.
When I looked at the actual file data, I saw that there are n times more rows of ...
I'd remove the space from the pool of valid password characters, and try again. Maybe you saw a less than 5 character password with some space character in front.
You don't have a break; after done = true;, which means the password is shortened by one character. Also, it's pretty pointless to allocate memory for both temp and out, but then assign one to the ...
While the output from your program may be encoding the plaintext, the problem lies elsewhere. The program spec says to prompt for input. The code above merely waits for input, without a prompt. Perhaps a review of the program spec is in order? There is specific instruction about the prompt and what follows.
One of the hidden lessons in the early psets is ...
Well, now you correctly check if the move tile and the blank tile are next to each other. It's not the shortest and not the most stylish way to do it, but OK. Then, in theory, you need to swap these two tiles, that is to assign board[i][j] = 0 and board[i2][j2] = tile, as simple as that, but instead:
swappy = tile;
tile = board[i2 - 1][j2];
The 2016 course deadline has passed. The 2017 submissions haven't opened yet. But you don't have to resubmit any psets that have already been graded, as your gradebook will carry over to the 2017 course. You need only submit psets that you haven't already submitted. (but not yet, as the 2017 submissions system is changing and is not yet ready).
Your problem lies in these lines:
for (int i = 0; i < n; i++)
if (values[i] > values[i+1])
If there are n elements in array values, what happens when i=n-1 and you try to look at values[i+1]? What is i+1? Is it a legal value for an array element?
This causes an element to be sorted out the end of the array and a 0 to be ...
I'm confident that check50 is working correctly after the thousands and thousands of times it has been run. So, without seeing your code, there's no way to know, but I have a theory. Every test that fails has three things in common.
It's always and only a first letter that is in error.
The first letter in the name is always already upper case.
I think you have to write #include <spl/gevents.h> instead of #include "gevents.h"
And you have to change also #include"gobjects.h" to #include<spl/gobjects.h> and also #include"gwindow.h" to #include<spl/gwindow.h>
And make sure that the "make file" in the same directory where is the breakout file exist.