Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: best way to return (char *)
Message-ID: <10436@socslgw.csl.sony.JUNET>
Date: 26 Jun 89 08:54:56 GMT
References: <7800013@gistdev> <2793@solo8.cs.vu.nl> <1989Jun23.170749.23253@utzoo.uucp>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 38

Someone:

>>>    .	Have the routine malloc() space, and let the caller free() it when
>>>	done with the returned pointer.

In article <2793@solo8.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:

>>In general you want to deal with the memory all on the same level.
>>It simplifies administration.

In article <1989Jun23.170749.23253@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

>Untidy though this approach is, it's often the best -- it alone avoids
>setting arbitrary bounds on the size of the returned value.

It's often necessary.  But there ARE other solutions.

>If you want to combine high speed and unbounded returned values and are
>willing to commit unspeakable acts to do it :-), have the caller pass in
>a buffer (and its size!) which is *usually* big enough, and have the
>function return either that buffer or (if it's not large enough) malloced
>memory.

That's not so unspeakable.  Compare it with one more solution, where the
caller remains responsible for the memory AND there are no arbitrary
bounds.  Have the function return either that buffer or (if it's not
large enough) a size of buffer that must be supplied by the caller next
time in order to get the complete result.  Or even more unspeakable,
simply advise the caller that the buffer wasn't big enough, but the
caller should keep the partial result obtained because it won't be
included in the result of the next call, and the total necessary length
isn't even known yet.  Now, would any Unix I/O routine be so unspeakable?

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
 The above opinions are claimed by your machine's init process (pid 1), after
 being disowned and orphaned.  However, if you see this at Waterloo, Stanford,
 or Anterior, then their administrators must have approved of these opinions.