textBuffer.h?No.
structs and functions to textbuffer.c?Yes! Make sure functions are declared static, and you document what the functions and structures you add are for.
<string.h>?Yes. It’s much, much harder if you don’t.
We’ll certainly be checking your submission with Valgrind for memory leaks.
TB be defined like link in the lecture examples?If TB points directly to the head of the list, functions like mergeTB cannot function correctly, as they may change the head of the list.
It’s a bad idea to clean up after yourself before abort(3)’ing if you have silly inputs, just in case the reason you got silly inputs spreads… Virtual memory also takes care of stopping memory leaks in this case.
newTB work?If the input text is, for example, "Hi\nhow\nare\nthings\n\0", the buffer should contain the following lines: { "Hi", "how", "are", "things" }. You will have to process the input string, extract all the substrings separated by newline, and copy them into the entries of your buffer structure.
'\n' characters in?Depending on your approach to splitting text, they may already be gone. The only other place you need the '\n' characters is in dumpTB, so you could probably get away without storing them…
Yes, text will always have a newline.
Each newline marks a new node in the text buffer. You need to track empty lines.
Yes! I (Jashank) recommend strsep(3), but both are valid. Note, however, that to use either, the input string needs to be mutable… and this isn’t guaranteed in the spec.
releaseTB?You cannot. You can’t write a black-box test for a destructor.
When you free(3) memory, all you’re saying is that you no longer need the block of memory you had a pointer to; it should be irrelevant to you whether that memory’s value changes or becomes invalid in some way, because YOU ARE ABSOLUTELY FORBIDDEN FROM ACCESSING THE MEMORY ONCE FREE’D. Use after free is an illegal and undefined operation. You have no way to invalidate the pointers (read: change any values outside your ADT, including outside pointer references to its state structure).
A good test that your releaseTB worked is that your program is still running after you do so.
One approach is to put a magic number at the beginning of your structure that indicates if it’s been releaseTB’d; if it has, you should abort(3) immediately because Something Very Bad Is Going On.
dumpTB return?NULL.
You should swap nodes, not the string pointers.
If somewhere in your textbuffer, you’ve got pointers to a particular node, and that node’s value changes, that node’s identity is lost.
Considering the context that we’re working on this data structure in – text editors – external code holding references inside your text buffer would get, understandably, quite upset if each node doesn’t persist its value.
With the exception of replaceText, each node’s value (in essence, the line of text it holds) should never, ever change.
mergeTB (tb1, 1, tb1)?Attempts to merge a textbuffer with itself should be ignored.
releaseTB as well?No! This will probably destroy both the source and destination textbuffers. However, you’ve moved the contents of the source textbuffer, so you can just free(3) as you would in releaseTB. You must not subsequently dereference it; that’s a use-after-free and (say it with me, folks!) use after free is illegal.
mergeTB?The correct behaviour should be as follows, for mergeTB (dest, pos, src):
pos=0: insert src before the start of dest.pos=linesTB(dest)-1: insert src before the last line of dest.pos=linesTB(dest): append src at the end of dest.str1 and str2 be the same size?No. You might be replacing one string with a longer string and your original chunk of memory may not be big enough. You will need to solve this problem.
You should search for, and replace, substrings.
No.
Yes.
""?Nothing is done in this situation. Nothing should be replaced.
Occurrences of the search string are removed.
diffTB change either of its textbuffer arguments?diffTB is non-destructive.