I know it's unlikely to be the real cause of the problem, but assuming that the code shown here is the actual running code, then it looks like there is a typo:
[tt]
<--in main function-->
char *teststring
<---- no semicolon
setstring(teststring, returnstring());
[/tt]
This would cause the compiler to treat the line as a function prototype,
[tt]char* teststring setstring(teststring, returnstring());[/tt]
That would certainly cause a puzzling compiler error of the sort you describe, and would be hideously hard to spot. A longshot, but I thought I'd bring it up.
(
NOTE: If you intentionally skipped the memory management details for this example, then feel free to ignore the rest of this advice. Otherwise, read on.)
In any case, this code shouldn't work at all: the strings aren't getting allocated, so there is no valid memory for setstring() (and hence clearstring(), copychars(), etc.) to work in - it uses the address the pointer is set to, addresss zero, which is probably not what you wanted. The compiler wouldn't complain, as this is a perfectly valid action as far as it is concerned, but it could lead to any number of runtime errors, with data or code overwriting, page faults, and/or segmentation faults being likely.
In the case of main(), you could simply declare a local char array more than large enough to hold the string, like this
Code: Select all
/* part main() */
char buffer[256];
char *teststring = &buffer;
However, this won't work for returnstring(); since local variables are stored in the function's stack frame, which gets deallocated when the function exits, so you'd be stuck with a wild pointer (one which could potentially scribble on the stack).
To get a string you can pass as a return value, you'll need to dynamically allocate the space from the heap. This can be done by getting the length of the source string, use that to allocate the memory for the pointers,
then copying the source string to the newly-allocated space. Whether this is done in the calling function or the copy function is up to you, provided that all allocated memory that is eventually deallocated (otherwise it would result in a memory leak). As a possible example (using the stardard memory functions - you'll need to implement your own, of course):
Code: Select all
#include "wpstrings.h"
#include <stdlib.h>
main()
{
char *sourcestring;
char teststring[256];
sourcestring = returnstring();
/* this pointer has to be captured so that it can be deallocated later */
setstring(&teststring, sourcestring);
/* note the reference operator - teststring is a char array, not a pointer */
free(sourcestring);
printf("%s", teststring);
}
char *returnstring()
{
? ? char *returnval = 0;
char test[] = "test";
returnval = (char *) malloc( (size_t) stringlength(test));
? ? setstring(returnval, test);
? ? return returnval;
}
BTW, this is even more of a problem with your concatstring() function; str1 has to have already allocated space sufficient to hold both strings in advance of the strings being concatenated. It isn't a bug in the function - the standard C function strcat() is nearly identical in behavior - but it does mean you need to take a few extra steps in using it that may not be obvious.
I was curious why you wrote these, rather than implementing the standard c-string functions (strcmp(), strcopy(), etc.). The functionality is very similar, just using different (admittedly less clumsy) names and not returning a value. I assume you have a reason for this, and I was wondering what it was.
EDIT: Added casts to malloc() call, fixed free() call.