Skip to main content
edited tags
Link
UpAndAdam
  • 1.7k
  • 1
  • 3
  • 20
added 1331 characters in body; edited title
Source Link

Pset5 Speller - Weird Load Function Bug (Edited w/ Code)

bool load(const char *dictionary)
{
    // TODO
    FILE *fdict = fopen(dictionary, "r");
    if (fdict == NULL)
    {
        return false;
    }

    // create container string to hold word
    char *string = malloc(sizeof(LENGTH+1));
    if (string == NULL)
    {
        return false;
    }

    // initialize new node
    node *n = malloc(sizeof(node));
    if (n == NULL)
    {
        return false;
    }

    //condition begins by scanning file
    while (fscanf(fdict, "%s", string) != EOF)
    {
        // assign values to n
        n->next = NULL;
        strcpy(n->word, string);

        // obtain hashcode for table
        int hcode = hash(n->word);

        // if no elements at hcode, fill with n. else, attatch table[hcode] as next and slot n as table[hcode].
        if (table[hcode] == NULL)
        {
            table[hcode] = n;
        }
        else
        {
            n->next = table[hcode];
            table[hcode] = n;
        }
        count++;

        n = malloc(sizeof(node));
    }

    free(n);
    //n = NULL;
    free(string);
    fclose(fdict);
    return true;
} 

load() code blockLoad Load() was working perfectly, except that it would not load the first word in the large dictionary, "a". I debugged for a whilebit and found that after initiating fscan() at on line 136 at the point in the loop where the longest word ("pneumonoultramicroscopicsilicovolcanoconiosis") would be scanned by fscan(), the last 12 characters of the longest word would immediately replace "a" where it existed in its linked list on the hash table before any data is actually allocated into a linked list.

The memory address remains the same, for all intents and purposes it is the same node, but now the n->word value would be changed to "lcanoconiosis". Does anyone know what might cause this? I'm completely at a loss, as nothing touches the hash table at this point in the loop. Theoretically I could hardcode an exception in check() to always count "a", but I'd rather know what's happening in case this happens again.

EDIT: included text of code instead of code screenshot (10/5/23)

Pset5 Speller - Weird Load Function Bug

load() code blockLoad() was working perfectly, except that it would not load the first word in the large dictionary, "a". I debugged for a while and found that after initiating fscan() at on line 136 at the point in the loop where the longest word ("pneumonoultramicroscopicsilicovolcanoconiosis") would be scanned by fscan(), the last 12 characters of the longest word would immediately replace "a" where it existed in its linked list on the hash table before any data is actually allocated into a linked list.

The memory address remains the same, for all intents and purposes it is the same node, but now the n->word value would be changed to "lcanoconiosis". Does anyone know what might cause this? I'm completely at a loss, as nothing touches the hash table at this point in the loop. Theoretically I could hardcode an exception in check() to always count "a", but I'd rather know what's happening in case this happens again.

Pset5 Speller - Weird Load Function Bug (Edited w/ Code)

bool load(const char *dictionary)
{
    // TODO
    FILE *fdict = fopen(dictionary, "r");
    if (fdict == NULL)
    {
        return false;
    }

    // create container string to hold word
    char *string = malloc(sizeof(LENGTH+1));
    if (string == NULL)
    {
        return false;
    }

    // initialize new node
    node *n = malloc(sizeof(node));
    if (n == NULL)
    {
        return false;
    }

    //condition begins by scanning file
    while (fscanf(fdict, "%s", string) != EOF)
    {
        // assign values to n
        n->next = NULL;
        strcpy(n->word, string);

        // obtain hashcode for table
        int hcode = hash(n->word);

        // if no elements at hcode, fill with n. else, attatch table[hcode] as next and slot n as table[hcode].
        if (table[hcode] == NULL)
        {
            table[hcode] = n;
        }
        else
        {
            n->next = table[hcode];
            table[hcode] = n;
        }
        count++;

        n = malloc(sizeof(node));
    }

    free(n);
    //n = NULL;
    free(string);
    fclose(fdict);
    return true;
} 

Load() was working perfectly, except that it would not load the first word in the large dictionary, "a". I debugged for a bit and found that after initiating fscan() at the point in the loop where the longest word ("pneumonoultramicroscopicsilicovolcanoconiosis") would be scanned by fscan(), the last 12 characters of the longest word would immediately replace "a" where it existed in its linked list on the hash table before any data is actually allocated into a linked list.

The memory address remains the same, for all intents and purposes it is the same node, but now the n->word value would be changed to "lcanoconiosis". Does anyone know what might cause this? I'm completely at a loss, as nothing touches the hash table at this point in the loop. Theoretically I could hardcode an exception in check() to always count "a", but I'd rather know what's happening in case this happens again.

EDIT: included text of code instead of code screenshot (10/5/23)

added 140 characters in body
Source Link

load() code blockLoad() was working perfectly, except that it would not load the first word in the large dictionary, "a". I debugged for a while and found that after initiating fscan() at on line 136 at the point in the loop where the longest word ("pneumonoultramicroscopicsilicovolcanoconiosis") would be scanned by fscan(), the last 12 characters of the longest word would immediately replace "a" where it existed in its linked list on the hash table before any data is actually allocated into a linked list.

Node before error:node before error

Node after scanning long word:node after error

The memory address remains the same, for all intents and purposes it is the same node, but now the n->word value would be changed to "lcanoconiosis". Does anyone know what might cause this? I'm completely at a loss, as nothing touches the hash table at this point in the loop. Theoretically I could hardcode an exception in check() to always count "a", but I'd rather know what's happening in case this happens again.

load() code blockLoad() was working perfectly, except that it would not load the first word in the large dictionary, "a". I debugged for a while and found that after initiating fscan() at on line 136 at the point in the loop where the longest word ("pneumonoultramicroscopicsilicovolcanoconiosis") would be scanned by fscan(), the last 12 characters of the longest word would immediately replace "a" where it existed in its linked list on the hash table before any data is actually allocated into a linked list.

Node before error:node before error

Node after scanning long word:node after error

The memory address remains the same, for all intents and purposes it is the same node, but now the n->word value would be changed to "lcanoconiosis". Does anyone know what might cause this? I'm completely at a loss, as nothing touches the hash table at this point in the loop.

load() code blockLoad() was working perfectly, except that it would not load the first word in the large dictionary, "a". I debugged for a while and found that after initiating fscan() at on line 136 at the point in the loop where the longest word ("pneumonoultramicroscopicsilicovolcanoconiosis") would be scanned by fscan(), the last 12 characters of the longest word would immediately replace "a" where it existed in its linked list on the hash table before any data is actually allocated into a linked list.

Node before error:node before error

Node after scanning long word:node after error

The memory address remains the same, for all intents and purposes it is the same node, but now the n->word value would be changed to "lcanoconiosis". Does anyone know what might cause this? I'm completely at a loss, as nothing touches the hash table at this point in the loop. Theoretically I could hardcode an exception in check() to always count "a", but I'd rather know what's happening in case this happens again.

Source Link
Loading