Why is my character array affected by unrelated code above it?

[btunde08]

This code was written specifically for the purpose of identifying a bug in another one of my programs. The first paragraph takes command-line input and encrypts it before printing the original and encrypted text. The second paragraph does the exact same thing, but with the original text hard-coded into it. It works exactly as I would expect it to, and if my command line is the same as the hard-coded text, their outputs are identical.

However, if I simply delete the first paragraph or us /* */ to ignore it, the second paragraph stops functioning properly and starts giving random output as part of the character array. Furthermore, I can determine what this output is by declaring an integer just above the array declaration. for example, adding the line "int a=66;" causes the character array to be followed by the character B (ascii 66) rather than otherwise random characters. I figured that this must have something to do with the way certain bits of memory are stored in character arrays, but I am at a complete loss for why this happens or what to do about it.

# include <stdio.h>
# include <cs50.h>
# include <string.h>
#define _XOPEN_SOURCE
#include <unistd.h>

char *crypt(const char *key, const char *salt);

int main(int argc, string argv[])
{
    char password[strlen(argv[1])];
    for(int i;i<strlen(argv[1]);i++)
        password[i]=argv[1][i]; 
    string enpassword=crypt(password,"00"); 
    printf("%s",password);
    printf("==%s\n",enpassword);
    
    char pass[3]={66,66,66};
    string enpass=crypt(pass, "00");
    printf("%s",pass);
    printf("==%s\n",enpass);
}

P.S. I am programming in C, not C++.

[48T7M4Gy]

P.S. I am programming in C, not C++. 

Most people would have noticed that and it is almost a good enough reason to not get involved because there appear to be a lot of limitations on successfully running it not least of which are the #include s.

However you need to do a couple of things:
1. Please put <> code tags around your code. Use the toolbox on the right --->
2. Your code should be properly indented and use whitespace to make it legible. I know C programmers like to bunch everything up but that practice died out with the Babbage Difference Engine. :)
3. Also have a function prototype that is hanging in mid air. Delete it please, but there again, you use it in main.
4. 2D array password[i]=argv[1][i]; is very suspect.

They're not huge problems but they make it easier to see what's going on and where people can help you. :)

[btunde08]

Sorry, I've only been programming for 2 weeks, and I just know the basics. B function prototype, do you mean the declaration of the crypt() function above main? I took the syntax from the man crypt main page, and I don't think my code works without it being declared before main().

[JLBorges]

# include <stdio.h>
# include <string.h>

char *crypt(const char *key, const char *salt) ; // -lcrypt: link with libcrypt

int main( int argc, char *argv[] )
{
    const char salt[] = "00" ;
    
    if( argc > 1 )
    {
        const size_t sz = strlen( argv[1] ) ;
        char password[ sz + 1 ]; // C99 vla; +1 for the terminating null character
        
        strcpy( password, argv[1] ) ;
        printf( " password: \"%s\"\n     salt: \"%s\"\nencrypted: \"%s\"\n", password, salt, crypt( password, salt ) ) ;
        
        // this would suffice; there is no need to make a copy of argv[1]
        printf( "\n password: \"%s\"\n     salt: \"%s\"\nencrypted: \"%s\"\n", argv[1], salt, crypt( argv[1], salt ) ) ;
    }
}

http://coliru.stacked-crooked.com/a/3fa6eef27e2200ae

[48T7M4Gy]

It's OK btunde08 I/we understand. Thanks for the code tags. If I can't help then there are plenty of other people who might jump in.

What I'd like to know about the function

crypt

is the code that goes with it. If you haven't got it or it is very long just a short description of what it does will help. By the look of it it is a process to encrypt a password with a key and it returns it as a c-string.

[48T7M4Gy]

Woo hoo! As it turns out:
http://www.delorie.com/gnu/docs/glibc/libc_662.html

//The next program shows how to verify a password.
// It prompts the user for a password
//and prints "Access granted." if the user types GNU libc manual.

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <crypt.h>

int main(void)
{
  /* Hashed form of "GNU libc manual". */
  const char *const pass = "$1$/iSaq7rB$EoUw5jJPPvAPECNaaWzMK/";

  char *result;
  int ok;
  
  /* Read in the user's password and encrypt it,
     passing the expected password in as the salt. */
  result = crypt(getpass("Password:"), pass);

  /* Test the result. */
  ok = strcmp (result, pass) == 0;

  puts(ok ? "Access granted." : "Access denied.");
  return ok ? 0 : 1;
}

[btunde08]

Yes, the crypt function does do what you just described, but my question is more abstract than just trying to get the right output. I need to understand why a character array (the one called "pass" in my code) which does not call on any variables at all is somehow affected by the code above it (which does not refer to it in any way).

If you cut everything down to the bare minimum, I really want to understand why this code prints "BBB" followed by random characters

int main(int argc, string argv[])
{
    char pass[3]={66,66,66};
    printf("%s\n",pass);
}

After playing around a little more, I concluded that it has to do with the input for the main function. By changing main function's input to "void", it starts behaving normally again.

[Chervil]

int main(int argc, char* argv[])
{
	char pass[3]={66,66,66};  // three characters, not a string
	printf("%s\n",pass);      // %s expects a c-string

}

int main(int argc, char* argv[])
{
	char pass[4]={66,66,66,0}; // three characters, followed by a zero
	printf("%s\n",pass);       // %s now receives a valid c-string

}

http://www.cplusplus.com/doc/tutorial/ntcs/

[48T7M4Gy]

Further to Chervil's comment ASCII 66 is the character 'B'
These are all the permutations of 3B's:

#include <stdio.h>
#include <string.h>

int main(int argc, char* argv[])
{
	//OPTION 1 - 3 B's NO terminator
	char pass1[3] = { 66,66,66 };
	int length1 = sizeof(pass1) / sizeof(char);
	printf("Pass1 = %s\n", pass1);	
	printf("Length1 = %i\n\n", length1);

	//OPTION 2 - 3 B's properly formed C-string
	char pass2[4] = { 66,66,66,'\0' }; // Note '\0' = 0
	int length2 = sizeof(pass2) / sizeof(char);
	printf("Pass2 = %s\n", pass2);	
	printf("Length2 = %i\n\n", length2);

	//OPTION 3 - C-string, terminator automatically added
	char pass3[] = "BBB";
	int length3 = sizeof(pass3) / sizeof(char);
	printf("Pass3 = %s\n", pass3);	
	printf("Length3 = %i\n\n", length3);

	return 0;
}

Pass1 = BBB╠╠╠╠╠%·ñⁿ  (See *** below)
Length1 = 3

Pass2 = BBB
Length2 = 4

Pass3 = BBB
Length3 = 4

*** Note:this kept going until a zero was encountered each time and the number and value of characters trailing the last B varies each time program runs.

[48T7M4Gy]

PS The above output is via VS2015. You'll not get the same result via the CPP shell. :)

(And sizeof(char) = 1 so this is a bit redundant in length calculation. C'est la vie.)

[btunde08]

Thank you very much, Chevril. It's good to know that I spent 6 hours scouring and testing code for something that was ultimately fixed with 4 keystrokes. As a side note, do you have any idea why this situation is only a problem with "int main(int argc, char* argv[])"?

If I use "int main(void)" the printf function doesn't seem to care that it isn't a valid c-string.

[Chervil]

"As a side note, do you have any idea why this situation is only a problem with "int main(int argc, char* argv[])"?

If I use "int main(void)" the printf function doesn't seem to care that it isn't a valid c-string. "

I don't think you should read any significance into that, it is in my opinion a spurious effect.

Think of it this way. When you put this:
char pass[3]={66,66,66}; the compiler has to allocate storage for those three characters. We have no way of knowing what values will reside in the adjacent memory locations. When the code is altered in any way, the contents of those memory locations may change.

You just happened to chance upon some combination where the next memory location contained a zero. But that doesn't mean the error went away. It only meant it was not visibly obvious from looking at the output.

If you look at the examples from Kemort above you will see various ways to address this. Changing the function header isn't one of them ;)

[48T7M4Gy]

There we go, I've just run it with args - all the same as predicted.

And also the un-terminated C-string produces new and different length garbage after the 3 B's in option 1
:)

[btunde08]

Thanks a lot, you guys. I appreciate the help.