Skip to main content
changed asterisk to apostrophe
Source Link
curiouskiwi
  • 18.7k
  • 2
  • 18
  • 43

Interesting issue. The problem is tied to the processing of asterisksapostrophes and memory allocation. It seems that, in the for loop, the second if statement is tripping on an asteriskapostrophe, but not the first one. It's more like several hundred asterisksapostrophes are processed before it seg faults. I haven't worked out precisely why, so if anyone tracks down the exact reason, feel free to chime in.

Having said that, I can identify the exact problem. The second if statement,

if(trav->letters[c % 97] != NULL)

is trying to test asterisksapostrophes (and line feeds, I'm sure). The problem is closely tied to trying to find trav->letters[c % 97], which works out to trav->letters[39]. Clearly, this is a problem. It can be easily fixed by using the same conditions used in the first if statement, as follows:

if(c != '\'' && c != '\n' && trav->letters[c%97] != NULL)

This cures this issue. You could also instead use isalpha() as a more reliable and comprehensive test, combined with the null checks.

The part that I haven't figured out is why it takes (in my testing) about 674 asterisksapostrophes successfully processed before it fails with a segfault. I would expect it to fail sooner, but apparently, it's not going outside of memory bounds until then. (Sometimes, bad addresses are actually valid in the allocated memory.)

Given that I've tracked down the error, I'll leave it to you to figure out the exact mechanism of failure, if you wish. You can enjoy spending more time on it. ;-)

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

Interesting issue. The problem is tied to the processing of asterisks and memory allocation. It seems that, in the for loop, the second if statement is tripping on an asterisk, but not the first one. It's more like several hundred asterisks are processed before it seg faults. I haven't worked out precisely why, so if anyone tracks down the exact reason, feel free to chime in.

Having said that, I can identify the exact problem. The second if statement,

if(trav->letters[c % 97] != NULL)

is trying to test asterisks (and line feeds, I'm sure). The problem is closely tied to trying to find trav->letters[c % 97], which works out to trav->letters[39]. Clearly, this is a problem. It can be easily fixed by using the same conditions used in the first if statement, as follows:

if(c != '\'' && c != '\n' && trav->letters[c%97] != NULL)

This cures this issue. You could also instead use isalpha() as a more reliable and comprehensive test, combined with the null checks.

The part that I haven't figured out is why it takes (in my testing) about 674 asterisks successfully processed before it fails with a segfault. I would expect it to fail sooner, but apparently, it's not going outside of memory bounds until then. (Sometimes, bad addresses are actually valid in the allocated memory.)

Given that I've tracked down the error, I'll leave it to you to figure out the exact mechanism of failure, if you wish. You can enjoy spending more time on it. ;-)

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

Interesting issue. The problem is tied to the processing of apostrophes and memory allocation. It seems that, in the for loop, the second if statement is tripping on an apostrophe, but not the first one. It's more like several hundred apostrophes are processed before it seg faults. I haven't worked out precisely why, so if anyone tracks down the exact reason, feel free to chime in.

Having said that, I can identify the exact problem. The second if statement,

if(trav->letters[c % 97] != NULL)

is trying to test apostrophes (and line feeds, I'm sure). The problem is closely tied to trying to find trav->letters[c % 97], which works out to trav->letters[39]. Clearly, this is a problem. It can be easily fixed by using the same conditions used in the first if statement, as follows:

if(c != '\'' && c != '\n' && trav->letters[c%97] != NULL)

This cures this issue. You could also instead use isalpha() as a more reliable and comprehensive test, combined with the null checks.

The part that I haven't figured out is why it takes (in my testing) about 674 apostrophes successfully processed before it fails with a segfault. I would expect it to fail sooner, but apparently, it's not going outside of memory bounds until then. (Sometimes, bad addresses are actually valid in the allocated memory.)

Given that I've tracked down the error, I'll leave it to you to figure out the exact mechanism of failure, if you wish. You can enjoy spending more time on it. ;-)

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

Source Link
Cliff B
  • 69.3k
  • 4
  • 33
  • 56

Interesting issue. The problem is tied to the processing of asterisks and memory allocation. It seems that, in the for loop, the second if statement is tripping on an asterisk, but not the first one. It's more like several hundred asterisks are processed before it seg faults. I haven't worked out precisely why, so if anyone tracks down the exact reason, feel free to chime in.

Having said that, I can identify the exact problem. The second if statement,

if(trav->letters[c % 97] != NULL)

is trying to test asterisks (and line feeds, I'm sure). The problem is closely tied to trying to find trav->letters[c % 97], which works out to trav->letters[39]. Clearly, this is a problem. It can be easily fixed by using the same conditions used in the first if statement, as follows:

if(c != '\'' && c != '\n' && trav->letters[c%97] != NULL)

This cures this issue. You could also instead use isalpha() as a more reliable and comprehensive test, combined with the null checks.

The part that I haven't figured out is why it takes (in my testing) about 674 asterisks successfully processed before it fails with a segfault. I would expect it to fail sooner, but apparently, it's not going outside of memory bounds until then. (Sometimes, bad addresses are actually valid in the allocated memory.)

Given that I've tracked down the error, I'll leave it to you to figure out the exact mechanism of failure, if you wish. You can enjoy spending more time on it. ;-)

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