If the length was known at compile time, it would be possible to wrap the string in a struct something like;
Code:
typedef struct {char buffer[20];} MyString;
and return that type.
With a string length that is unknown at compile time, there are some choices, but none are perfect.
1) Use a memory pool (aka a static pointer that is local to your function, and reallocated as required). For example;
Code:
char *FunctionThatReturnsString(int length)
{
static char *buffer = NULL;
if (buffer != NULL) /* be pessimistic */
free(buffer);
buffer = malloc(length);
/* put something into buffer */
return buffer;
}
One problem with that the strings returned may not have sufficient lifetime, and the function therefore cannot be called more than once between two sequence points. For example, the call;
Code:
SomeFunction(FunctionThatReturnsString(10), FunctionThatReturnsString(20));
will yield undefined behaviour if SomeFunction() dereferences it's arguments, as one of the arguments will be a dangling reference. It also yields a memory leak on the last call.
2) Use a buffer that exceeds any length needed by your program. Apart from the problem of picking a buffer length that is "enough", this also has problems with multiple calls between sequence points (the value copied to the buffer may not survive) and is also extravagant use of memory if the largest required buffer size is significant. But it does not cause a memory leak as such.
3) Wrap the call to MessageBox in a suitable manner that cooperates with your MyFunc(). For example;
Code:
char *MyFunc()
{
char *buffer = malloc(1000);
/* put something in buffer */
return buffer;
}
void MyMessageBox()
{
char *temp = MyFunc();
MessageBox(0, temp, "Test Output", 0);
free(temp);
}
A problem with this is that it relies on the programmer (who may or may not be yourself) being disciplined enough to use MyMessageBox() rather than MessageBox(). Another problem is that it may be necessary to write a significant number of such functions.
4) Program in C++, and use the standard string class from C++. Technically, this has a trade-off as effective programming techniques in C are not necessarily the most effective in C++ (and vice versa). It also has a political trade-off, as bigoted C programmers will accuse you of going to the "dark side" but bigoted C++ programmers will welcome you with open arms for coming from the "dark side".
Originally Posted by mas0
