"*entry = 0;" or "entry[0] = 0;" are the same thing. They both set the first byte of entry to zero leaving the other bytes unchanged. (Assuming entry is a char array)
"memset(entry, 0, ENTRY_SIZE);;" will set as many bytes of entry to zero as specified by ENTRY_SIZE, which I'm assuming is defined to be the size of that array, so all the bytes.
As we are dealing with strings here we only need to set the first byte to zero, the string terminator, to make it look like the is a zero length string in the array. The other bytes don't matter then.
I have come to the conclusion, that I have a nul termination problem somewhere, but most likely in several places. So I will have to go over all my code with a fine tooth comb, just to ensure that everything is properly terminated
Did I mention that I miss the MFC CString class functions?
It's 99% certain that you have such a termination/overrun error in there somewhere. That's how it goes with C and strings/buffers.
Always use the "n" versions of the string and memory functions from the standard library. That is strncpy/stpncpy instead or strcpy/stpcpy etc.
A common mistake, well one that I have made, is to have an array of say 10 bytes long and then be storing strings in it with a max string length of 10. Forgetting about that pesky null termination.
C++ has excellent string handling in it's std library. No need for an MFC. I suspect using that would probably blow the code size through the roof though.
A common mistake, well one that I have made, is to have an array of say 10 bytes long and then be storing strings in it with a max string length of 10. Forgetting about that pesky null termination.
I think I am in pretty good shape for that scenario, but I may have overlooked a size issue or two. I am more inclined to believe there is an issue with several strcpy(s).
C++ has excellent string handling in it's std library. No need for an MFC. I suspect using that would probably blow the code size through the roof though.
Yea, it is already up there in size, and I still have to insert the code in the actual parsing code, for the firmware. So I believe C++ is out of the picture.
The nice thing about the MFC CString class, is that they have class member functions for almost anything that you would want to do with a string, then for arrays and lists of CString, there are the CStringArray and CStringList classes, with there wide array of their own member functions. With those three classes, you can perform some pretty powerful manipulation and tracking, very quickly and quite easily. String handling for dummies
In fact, it was those three classes that drew me to MFC in the first place, and then I discovered that MFC made programming so much easier than than using C++ or C. Instant code generation.... What's not to love
Okay, you got me there.... I cannot deny that stance, but for a Windows app, it decreased development exponentially. And then, if MFC did not provide the support needed, you could just use the Windows API functions, to get the best of both worlds.
SD card directory and file navigation through the use of 6 pushbuttons, two LEDs, and a 4 line LCD.
Build error and warning free.
It works well Or at least good enough for me Now back to the firmware
EDIT: If you find any errors, please let me know.
EDIT: For the sake of completeness, I am now adding a schematic for the project below. Please note that I previously mentioned two LEDs, but there are actually three, with one of them, simply indicating power to the user interface board.
Comments
Thanks for your input..... the actual c string functions are driving me a tad bonkers. I wish they had a more in depth library for manipulation.
What is the difference between *entry = 0; and memset(entry, 0, ENTRY_SIZE); ?
"memset(entry, 0, ENTRY_SIZE);;" will set as many bytes of entry to zero as specified by ENTRY_SIZE, which I'm assuming is defined to be the size of that array, so all the bytes.
As we are dealing with strings here we only need to set the first byte to zero, the string terminator, to make it look like the is a zero length string in the array. The other bytes don't matter then.
Thanks again for the info.
I have come to the conclusion, that I have a nul termination problem somewhere, but most likely in several places. So I will have to go over all my code with a fine tooth comb, just to ensure that everything is properly terminated
Did I mention that I miss the MFC CString class functions?
Always use the "n" versions of the string and memory functions from the standard library. That is strncpy/stpncpy instead or strcpy/stpcpy etc.
A common mistake, well one that I have made, is to have an array of say 10 bytes long and then be storing strings in it with a max string length of 10. Forgetting about that pesky null termination.
C++ has excellent string handling in it's std library. No need for an MFC. I suspect using that would probably blow the code size through the roof though.
I think I am in pretty good shape for that scenario, but I may have overlooked a size issue or two. I am more inclined to believe there is an issue with several strcpy(s).
Yea, it is already up there in size, and I still have to insert the code in the actual parsing code, for the firmware. So I believe C++ is out of the picture.
The nice thing about the MFC CString class, is that they have class member functions for almost anything that you would want to do with a string, then for arrays and lists of CString, there are the CStringArray and CStringList classes, with there wide array of their own member functions. With those three classes, you can perform some pretty powerful manipulation and tracking, very quickly and quite easily. String handling for dummies
In fact, it was those three classes that drew me to MFC in the first place, and then I discovered that MFC made programming so much easier than than using C++ or C. Instant code generation.... What's not to love
The non-portability.
The hungarian notation used in MS software.
Okay, you got me there.... I cannot deny that stance, but for a Windows app, it decreased development exponentially. And then, if MFC did not provide the support needed, you could just use the Windows API functions, to get the best of both worlds.
However, as you say, non-portable.
SD card directory and file navigation through the use of 6 pushbuttons, two LEDs, and a 4 line LCD.
Build error and warning free.
It works well
EDIT: If you find any errors, please let me know.
EDIT: For the sake of completeness, I am now adding a schematic for the project below. Please note that I previously mentioned two LEDs, but there are actually three, with one of them, simply indicating power to the user interface board.