Thread: retreiving variable from within loop.

Hmm, the program compiles when I fix this error:

Code:

char key[16] = "aeiluozcgraolifi";
//27 initializer-string for array of chars is too long

Other than that there may be better ways to get the size of the file than getting 150000 characters and then counting how many there actually is.

And then

Code:

for(x = 0; x < count; x++){
            encrypt[x] = file[x] ^ key[x];
            }

The length of key was only 16. On my particular run the program didn't crash, but since there apparently were 0-bites beyond key, only the beginning of the text got encrypted.
I would use x%KEYSIZE to get the index for key[] in the loop.

So I gather you're experimenting with XOR encryption? (Sometimes it's easier -- and better -- to state the problem, and/or the "big picture", rather than perceived issues with assumed solutions.) Anyways, a number of your latest posts seems to point me toward that.

And it's been kinda slow, and I've never written one that I can remember, so I decided to play along at home. Here is something to compare with after you've finished or as you continue developing your code. I'm sure others will be along soon to nitpick it as well.

Code:

#include <stdio.h>
/*
 * argv[1] - name of input file to encrypt/decrypt
 * argv[2] - name of output file
 * argv[3] - crypt key
 */
int main(int argc, char *const *argv)
{
   if ( argc == 4 )
   {
      FILE *input  = fopen(argv[1], "rb");
      FILE *output = fopen(argv[2], "wb");
      if ( input != NULL && output != NULL )
      {
         unsigned char buffer[BUFSIZ];
         size_t count, i, j = 0;
         do {
            count = fread(buffer, sizeof *buffer, sizeof buffer, input);
            for ( i = 0; i < count; ++i )
            {
               buffer[i] ^= argv[3][j++];
               if ( argv[3][j] == '\0' )
               {
                  j = 0; /* restart at the beginning of the key */
               }
            }
            fwrite(buffer, sizeof *buffer, count, output);
         } while ( count == sizeof buffer );
         fclose(input);
         fclose(output);
      }
   }
   return 0;
}

Doing something like this...

H:\Forums>xorcrypt main.c file.bin key
H:\Forums>xorcrypt file.bin file.txt key

You should find that main.c matches file.txt.

Code:

for(x = 0; x < count; x++){
            encrypt[x] = file[x] ^ key[x];
            }
            printf("%s", encrypt);

KABLAM.

Surely one of the XOR operations will produce zero, by chance. encrypt[x] is non-zero up to a certain x. You will only see the first x characters printed. After that, well, there goes. printf() will die there and then because it has encountered a zero character.

Listen everyone, it gets better...

And what if no zero character is produced? Then printf() will print all 150,000 bytes of encrypt and perhaps more, until it does reach a zero.


Toodles.
~

Originally Posted by jafet

Code:

for(x = 0; x < count; x++){
            encrypt[x] = file[x] ^ key[x];
            }
            printf("%s", encrypt);

KABLAM.

Surely one of the XOR operations will produce zero, by chance. encrypt[x] is non-zero up to a certain x. You will only see the first x characters printed. After that, well, there goes. printf() will die there and then because it has encountered a zero character.

No it won't:

Code:

#include<stdio.h>
int main( void )
{
    char foo[] = { 0 };
    printf("%s", foo );
    return 0;
}

It will simply print nothing. A string is defined as zero or more characters, terminated by a null character. If all you have is the null, you have what is considered an empty string. It's still a legal string. Thus, any Standard C function which handles strings, will still be able to handle it.

Originally Posted by jafet

And what if no zero character is produced? Then printf() will print all 150,000 bytes of encrypt and perhaps more, until it does reach a zero.

So? As long as you're not running off the end of your allocated space, who cares how much it prints? It's still legal, assuming you are in fact staying in bounds of your allocated space.


Quzah.

Yep, so printf only prints part of the string... that's prolly why the OP thought the rest of the data had "vanished"...