With regards to the multiple static return buffer technique most recently posted by John Winters, brucemo@seanet.com wrote:

> I think that technique is awful because it adds unnecessary "cute" code,
> uses up 200 bytes of static data, introduces something you need to
> document (the fact that buffers returned by the function eventually will
> get over-written), and introduces bugs (caused by the above time-bomb
> combined with failure to read or remember this documentation), all in a
> dubious effort to save someone the hassle of allocating a buffer on the
> stack and passing a pointer to this buffer to the function.
>
> Sorry, but this thread has made me cringe. I can't stand to see people
> turn a simple function into a complicated "system" for no reason. This
> kind of coding leads to byzantine structures that make the person you
> hand your code off to want to drink too much.

It all depends. In many circumstances, I'd agree with you completely that gratuitous complexity or cleverness serves only to stroke the original coder's ego and to make everyone else's lives miserable. But not always.

Software engineering is all about managing complexity. If you've got complexity spread out all over the place, sort of like the pink sludge in The Cat In The Hat Comes Back, you've got problems. And if you or Little Cat Z can figure out a way to sweep at least some of the complexity off into one little corner, so that you can ignore it except when you have occasion to venture into that corner, then that's a good thing.

I'm lazy. I like simple code, that's easy to understand and that writes itself. But I will occasionally bend 'way over backwards, and toil away an entire day writing some miserably complicated, excessively general function, if that function will then serve as a workhorse which I can punt all the hard work to from the rest of the program, such that the rest of the program becomes pleasantly, falling-off-a-log easy to write.

In C, at least, returning strings from functions can be a little bit hard, and any technique for doing so is more complex than it is to return a simple, non-aggregate value. When you're specifying any functional interface, it's often a delicate question how much of the work you should have the function do and how much you should require the caller to do. It's not enough that the specification be correct and complete; if it's too cumbersome to use, or makes the caller do too much work, then the would-be caller may get discouraged, and decide that it's too much trouble to call the function after all, such that the benefit of having the function is at least partially lost. The tradeoffs can be subtle, and can depend on many things, but it's certainly not possible to (in this case) declare unilaterally either that the caller should always allocate space for the string result, or that the function should always allocate it. Different situations may require different approaches (at least for best results).

The multiple static return buffer technique certainly isn't a panacea. John wasn't advocating using it all of the time, and although it's a technique I like a lot, I hardly ever find myself actually using it, either. But once in a while, the tradeoffs are such that it is quite attractive and (I believe) appropriate.

Some time ago, I wrote a long article discussing some of the options for returning strings and other aggregates, and their relative merits and applicability. I was going to mount a search for it, but then last night, in a directory and on a machine where I wouldn't even have looked, I came across a copy (as it happens, while looking for directories to clean up to save some disk space). Here it is.

[Well, there it was, but an hour later I found another one...]

From: scs@eskimo.com (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: function that returns string [repost]
Date: 23 Jun 1997 22:15:07 GMT
Message-ID: <5omshb$4jg$1@eskinews.eskimo.com>
X-Original-Date: 18 Jun 1997 18:53:06 GMT
X-Original-Message-ID: <5o9aqi$fcq$1@eskinews.eskimo.com>
See-Also: <CrHu2G.D3B@eskimo.com>

In article <5o974l$df6$1@eskinews.eskimo.com>, I wrote:
> Some time ago, I wrote a long article discussing some of the
> options for returning strings and other aggregates, and their
> relative merits and applicability. I was going to mount a search
> for it, but then last night, in a directory and on a machine
> where I wouldn't even have looked, I came across a copy (as it
> happens, while looking for directories to clean up to save some
> disk space).

And I was so pleased at having done so that I neglected to follow through on this nagging feeling I had that the article I'd just found didn't do as much discussing of tradeoffs and relative merits as the one I remembered. Then, when I went to put the one I'd just found in the directory where it belonged, sure enough, there was another file there (of exactly the same name; determinism strikes again) containing this article (which I have edited lightly for this posting).