1

I'm a complete newbie trying desperately hard with this pset for the past month. At best I've got the following but this isn't working.

I think my shift function is ok, and I know at the moment it's written to print integers at the end, but even the integers are not the correct ASCII.

If you run the code it spits out four integers even when the length of plaintext was only 3 characters. Please let me know what you think?

#include <cs50.h>
#include <stdio.h>
#include <string.h>
#include <ctype.h>
int shift (char c); // declaring prototype of a function that converts char into shift value

int main(int argc, string argv[]) // Counting command-line arguments
{
    if (argc == 2)
    {
        string s = argv[1]; // string of user's key
        int l = 0;
        while (s[l] != '0')
        {
            l++
        }

        int i = 0 // validating user's key
        while (i < l)
    {
        if (isalpha(s[i]))
        {
            i++;
        }
        else 
        {
            printf("Usage: ./vigenere keyword\n");
            return 1;
        }
    }
    string plaintext = get_string("plaintext: "); // prompt for plaintext
    {
        printf("ciphertext: ");
        for (int a = 0, n = strlen(plaintext); a < n; a++)
            {
                int key = shift(s[l]);
                int ciphertext = (int)plaintext[a];
                    {
                        printf("%i + %i", ciphertext, key);
                    }
                l++;
            }
    printf("\n");
    }
}
else
{
    printf("Usage: ./vigenere keyword\n");
    return 1;
}  
}
int shift(char c) // Fx shift: getting the integer of key for each char
{
    int key = (int)c;
    if (65 <= key && key <= 90)
    {
        return (key - 65);
    }
    else if (97 <= key && key <= 122)
    {
        return (key - 97);
    }
    else
    {
        return 1;
    }
}
12082019
  • 11
  • 1
  • Elements of a CS50 `string` can not safely be used with functions such as [`isalpha()`](https://port70.net/~nsz/c/c11/n1570.html#7.4.1.2). `string` is nothing more than an obfuscated `char *`, while functions such as `isalpha()` take `int` arguments. On an implementation with a signed `char`, values will be sign-extended before being passed to `isalpha()` *et. al*., and not properly interpreted. That's **another** reason to abjure CS50's benighted `string`. – Andrew Henle Nov 13 '19 at 14:25

1 Answers1

0

Many things to work through here.

  1. This code does not compile in the CS50 Lab.
  2. This code does not accept user input because of this line while (s[l] != '0'). That is looking for the character zero (0). The intention is likely to look for the null terminator, which is written as '\0'.
  3. The output here printf("%i + %i", ciphertext, key); is visually confusing because it displays 2 tokens for each plaintext character. That could be why it appears to spit out "four integers even when the length of plaintext was only 3"
  4. The if tests in shift are incorrect. It should be looking for characters between the two values. One of the tests, in each case, needs to be a >=.
  5. Program does not manage the key index properly. It should never try to access an index of key that is greater than the length of key. Since the program always increments key index, it goes beyond the end of key (and it starts processing with the last character if key!). This looks like a good caesar shift, where the "key" is one character, but it is not constructed properly for vigenere. It needs to implement the key index as described in the spec:

Remember also that every time you encipher a character, you need to move to the next letter of k, the keyword (and wrap around to the beginning of the keyword if you exhaust all of its characters). But if you don’t encipher a character (e.g., a space or a punctuation mark), don’t advance to the next character of k!

You may find this walkthrough (from an earlier version of the course) helpful.

A style note: Consider changing the variable named l to something else. When reading the code the letter l is indistinguishable from the number 1 and makes the code ambiguous and difficult to follow.

DinoCoderSaurus
  • 6,110
  • 2
  • 10
  • 15