I've searched extensively for someone with a similar problem in the forums, but I have yet to find an answer.

I have implemented load() with a trie.

With my implementation of load() in pset5 "speller," I was encountering issues with the way it handled characters from the dictionary file and a conflict with the new line '\n' character. Initially I took the alphabetic characters from fgetc() and subtracted 'a' to reinitialize them to digits 0-25 with the apostrophe character assigned to digit 27 in order to traverse the children of the trie, but I was encountering many issues when running check. I discovered through using debug50 that when loading the dictionary, every time it encountered a '\n' in the dictionary, it changed my variable to it's ASCII value '10' and was traversing the trie through array spot 10 every time the dictionary encountered a '\n' or the letter k.

I ended up using a workaround by increasing the array by 1 space and skipping over the 10th array spot. I ended up noticing a similar issue in my implementation of check() and the terminator '\0' character where my trie path for 'a', assigned to array space 0 was also being traversed by the '\0' character. I had to add another workaround where I added yet another spot to my node array and shifted everything 1 space to the left, leaving open spot 0 and 10.

It compiles, loads checks and returns the correct output, however I believe it is giving me some problems down the road when it comes to memory leaks and I'm sure this is not the way the function was intended to be implemented, nor is it efficient or intuitive.

tl;dr - I've had to create a workaround by increasing the size of my node arrays by 2 and leave open spots 0 and 10 (to avoid conflict with '\0' and '\n' in order for my program to give the desired input. Help me figure out why.

My implementation of load is in this github gist:


And my implementation of check() is here:


Any help with this would be greatly appreciated. Thanks in advance!


So, why are you processing \n and \0 into the trie at all? Instead, wouldn't it make more sense to use \n as a signal to mark the previous letter as the end of a word and prepare to process the next word?

  • Thank you - this made me think about this problem a little differently and I was able to rewrite load passing the characters of the dictionary into a temporary word buffer to use to create my trie. It now passes load and check with the correct output using a node array of 27 instead of 29 characters. Now on to that pesky unload function! – pobug Apr 3 '17 at 22:46
  • Congratulations.Although, I always wonder why everyone has to read the word into a buffer first, instead of processing the letters directly into the nodes of the trie. Hmmm..... ;-) – Cliff B Apr 3 '17 at 23:26
  • Aw man, just when I thought I could move on, I read this and now I'm obviously going to have to go back and figure out how to do this without the buffer array! Always interested to learn a better/more efficient way to solve the problem, though, so thanks for the suggestion - I'll see if I can work that out! – pobug Apr 3 '17 at 23:56
  • Okay - I cast the converted characters of the dictionary words into an int variable while not converting the '\n' characters and then created the trie only using the converted variable as the place holder and that seemed to do it. Thanks again so much for the mysterious hints! – pobug Apr 4 '17 at 2:11
  • Cast them into an int? Hmmm, if only there were some other var type that looked like a char.... you know,.... an unsigned one byte something or other..... (and you thought you were done. ;-) ) – Cliff B Apr 4 '17 at 3:18

You must log in to answer this question.

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