You should use strcmp, not "==" when comparing two strings in c. The strcmp function, included in string.h takes in two parameters, your two strings, and outputs 0 if the strings are equal. If you need more info, check it out on cs50 reference. Therefore, the problem lies in:
if (result == hash)
Hope this helped!
Let's take a look at the man page of strcat():
char *strcat(char *dest, const char *src);
The strcat() function appends the src string to the dest
string, overwriting the terminating null byte ('\0') at the end of
dest, and adds a terminating null byte.
So, it seems that strcat() doesn't just return to you a new string with the result of the ...
In C a string name is just a pointer to the actual string located somewhere
in memory ending with a NULL character. So when you use the "==" operator to
check it's equality you are basically comparing the pointers (the memory
address it's pointing to). But the strcmp() function takes in two 'pointers
to string' (the name of string) as parameters and ...
Ok, I've found answer to c segmentation fault on tail recursion:
changing clang option -o from 0 to 3 fixes this problem as this enables better optimization:
clang -fsanitize=integer -fsanitize=undefined -ggdb3 -O3 -std=c11 -Wall -Werror -Wextra -Wno-sign-compare -Wshadow crack.c -lcrypt -lcs50 -lm -o crack
if(!offset) offset = 0; does nothing. 0 is the value of false, while anything different could be interpreted as true in many contexts (even if it does not equal true, which is 1).
With word[offset=='z'], you probably meant word[offset]=='z'?
I haven't completely understood your algorithm, but as there are 52^4+52^3+52^2+52^1 (+1 for empty string) different ...
Maybe you are confusing two things. Those words on the left ("rob", "brian") are user names. The hashes are hashes of the associated passwords. That's a format you might find in the /etc/passwd file of a Linux system. I think there's a bit more on that in the problem's page, but if you're new you might still miss that bit.
Did you let it run to completion or did you stop it while it was still running? This pset is notorious for running very long times for 5 letter passwords. Try running it overnight and see if it completes. If not, then post a comment that it failed.
You might also try moving the lines of code that set the last char to \0 outside of the respective loops to ...
I have used recursion, wrapped inside one loop for the number of digits. Which I think is the same approach mentioned by User20025. The recursion concept is that a 3 letter password is 1 letter plus a 2 letter password. The whole thing finds the password for Malan (NOPE) in 15 seconds in the IDE50. The max loop (ZZZZ) is done in 25 seconds.
I'd say crypt works as expected, and is not the cause for your problem.
Passing z or z_val does the same thing, as arrays are passed as a pointer to their first element. Same goes for returning o or output. And here's a problem: The array output got declared on to_password's stack. When it returns, that area of the stack will be marked as "unused" (the ...
argv  is, in effect, a string, however the statement:
It is incorrect. What are you really saying? Keep in mind that the variable of type string does not exist in c, it is a typedef of char *, a pointer of type char, which is the type of variable that is normally used to handle strings. So your statement really says that you declare an ...
Yes, you can have password that are mixed case. I believe you already know how to join strings or individual chars together, for example from exercises where we learn to printf "Hello" + name together. Can you use something like that to join together different chars?
For the question about generating both lower and uppercase letters: have you considered ...
The salt must be saved together with the hash, so that we can reproduce the result. A password check function would hash a password using the same salt and compare the results. The salt here are the first two characters of the hash.
Correct, though I would not say "encrypt" here. The password is not the thing that's encrypted, but the source of the key to ...
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 ...
The UndefinedBehaviorSanitizer (aka UBSan) relates to execution-time bugs caused by various kinds of undefined programme behaviour. For instance,
Using misaligned or null pointer,
Signed integer overflow, or
Conversion to, from, or between floating-point types which would overflow the destination.
The odds are the line 65 seating characters[c4] access an ...
Keep in mind that a "string" in C is simply a character array that is null terminated.
As such, your salt variable is not a string, nor is your temp variable in all cases.
As a consequence, when you call crypt, which is expecting 2 strings, it will look at the location of each string and keep reading until it finds the null char that signifies the end. If ...
This program takes a notoriously long time to run. It's also an exercise in making code more efficient. Also, at this point, you should start being able to answer questions on your own, like this one:
Is there something wrong with [my code]?
Good question. Did you run tests and get valid and correct answers? Did you encode simple passwords on your own ...
Where's the end of string marker \0?
printf will keep printing whatever follows in memory until it sees the EOS marker, even into other areas of memory.
If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)
char candidate is a char array with 5 chars. It is not a 'string' which is what crypt needs. (a string is a char array that ends in a null char).
I'm actually surprised you are finding any passwords given that you are passing a non-null terminated array to crypt. But I'd guess the ones you aren't cracking are 5-character passwords.
The problem was hiding somewhere else:
// Create pword w/ max of 5 chars
pword = '\0';
That means that the first 4 chars are whatever random garbage is in them when the char array is created. So, what's in the first 4 chars as the code progresses? More importantly, where is the end of string marker when you're dealing with 1 and 2 char ...
pw = check[i];
at this point, pw is not a string. A string is a char array terminating in the null char. You've set pw to 'a' but the next 4 chars in pw are still garbage values, so using pw in crypt will give you unreliable results.
Be sure to null-terminate any array that you want to treat as a string.
When you read the man page for crypt, you maybe missed this:
The return value points to static data whose content is overwritten by each call.
Each time you call crypt, the static string that password_hash points to is being changed to the new return value, and both strings are pointing to the same static value.
You can see this if you change your print ...
The 'more comfortable' problems seem to be geared toward people who have at least a little prior experience in programming. The entire problem can be solved with arrays and loops (in under 100 lines of code), so you don't need anything specific from subsequent lectures. As you complete more lectures and problem sets, you'll gain some of that experience and ...
It doesn't work: string1 == string2. Even if they are equal you won't get "true". You should compare them char by char. Happily, somebody has already coded special function available in string.h: strcmp(string1, string2) which returns 0 if they are equal.
You should check not only 3 or 4 char passwords, but 1 and 2 as well.
I'm puzzled about ...
It looks like strcmp() isn't being used as it should. ( I don't understand why the result of strcmp is being checked for > 1. )
The strcmp(s1, s2) function compares two strings, char by char and returns one of 3 possible results. If the strings are identical, it will return 0. If the first unmatched char in s1 is smaller than the char compared in s2, then ...