Having read the other posts I am still unable to solve the problem created by white space. Belows code only deals with the key as not to post too much code publically. The white space is not handled by the final else statement. I also tried inserting an if/else == ' ', but this did not work either.

int main(int argc, char *argv[]){
        if(argc != 2) {
                printf("Error on input");
        string input = get_string("Input:");
        string key = argv[1];
        int len = strlen(key);
        int keys[len];
        for (int i = 0; i < strlen(key); i++) {
                if(isupper(key[i])) {
                        keys[i] = key[i] - 65;
                } else {
                        keys[i] = key[i] - 97;

        for(int i = 0; i < strlen(input); i++) {
                if(isalpha(input[i])) {
                        // if upper case to this

                        if(isupper(input[i])) {
                                // get keys from array above
                                int convertKey = keys[i % (strlen(key))];

                                printf("%i\n", convertKey);

                        }  else if(!isupper(input[i])) {
                                int convertKey = keys[i % (strlen(key))];

                                printf("%i\n", convertKey);

                } else if(isalpha(input[i]) == false) {
                        // or !isalpha(input[i])
                        // or (isalpha == ' ')
                        printf("%c", input[i]);

When I enter:

./vigenere bacon
Meetme => 10214131
Meet me => 10214 10

Above shows wrap skips the 13, but this is not even the white space (*edit- I see that it is now actually). I think the i is accessing the incorrect element in the keys array. I don't know how to stop the wrap from moving during the space though, or know how to fix.

1 Answer 1


The code uses the same index, i, to control the plaintext and the key. On each pass through the loop, a plaintext char is ALWAYS consumed, but a key char is ONLY consumed when the plaintext is an alpha and NEVER when the plaintext is not an alpha. The key needs a different index var and the two indexes must be independent. Also, the key index must ONLY be incremented when an alpha is consumed from the plaintext.

Don't overthink it. There is actually a very simple solution (and it isn't a second for loop, so don't go there.)

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)

  • 1) add j to loop 2) made a counter independent of loop. Neither work. With j in loop, key=bacon plaintext=MEET ME => NEGb ZF; key=bacon plaintext=meet me => neg zf j++ is only when i isalpha now. Maybe the error is obvious? gist.github.com/chrisdel101/ecaa806ebfb0036181b113705d0b932a
    – Mote Zart
    Commented Feb 19, 2018 at 3:09
  • You fixed the index issue, it's working fine. But there are a number of unrelated issues remaining, such as line feeds in the output, missing output (reread the pset instructions on what the output should look like) and the calculation of the encoded text, perhaps more issues. You need to go back and try to figure out what's wrong in each case and try to work through the debugging. If you have a question on a new issue, please open a new question. I want you to have a chance to work through it. The most important skill you can develop as a programmer is how to debug. This will give you that.
    – Cliff B
    Commented Feb 19, 2018 at 3:37
  • Man C is a stubborn language. I got it working by fixing the bracket issues in the formula section (will delete the gist after we are done here). I went with counter since j would not work. The brackets were screwing up things too. It still fails the check50 though, even with plaintext and ciphertext added, and output looking like check50. Hard to debug this one since it doesn't give the nice `expected output' field the Caesar problem did- made it easy to fix!. Is my code off? Or is this a simple formatting error now that makes it fail?
    – Mote Zart
    Commented Feb 19, 2018 at 4:00
  • Well, since I can't see the new code (don't edit the question) and my crystal ball is in the shop, I'll say that there's still something wrong, but that you're getting it. It just seems hard right now because its new to you. By the time you get to pset6, you'll come back and say "that was so simple..." My next recommendation is to think about your code and its complexity. The simplest code is usually the best. Keep it simple! Have fun!;-)
    – Cliff B
    Commented Feb 19, 2018 at 4:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .