Re: return a string

Keith Thompson wrote:
>
> Daniel Haude <haude@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> > On 29 Apr 2005 14:04:10 -0700,
> > Nascimento <underscore0x5f@xxxxxxxxx> wrote
> > in Msg. <cbecb304.0504291304.57f9f42d@xxxxxxxxxxxxxxxxxx>
> >> Hello,
> >>
> >> How to I do to return a string as a result of a function.
> >
> > All the answers you ever needed were already given. Here's a summary
> > (which I only post to reflect ,y own knowledge on the subject matter --
> > this is an invitation to the gurus to tear it apart).
>
> Good answers, but I have a couple of quibbles.
>
> > 1. Declare a static array of char in your
> > function and return it (as the
> > asctime() function does). Simple but very limited.
> > Problem: printf("%s %s\n", foo(a), foo(b));
> > prints the same thing twice.
>
> I've used a variant of this. I had a function returning char* that
> declared two local static variables, an array of arrays of char (for
> the results), and an index. On each call, it would cycle the index
> through the array and use a fresh sub-array for the result. This
> allowed, say, half a dozen distinct calls to be active simultaneously.
> It's not pretty, and it still forces you to decide in advance both how
> big the result can be and how many distinct results you need, but it's
> a bit more flexible than using a single static array.
>
> > 2. malloc() memory for the string inside your function
> > and return pointer
> > to it. Simple but ugly because you have to remember
> > to free the memory
> > later. Problem: printf("%s\n", foo(a));
> > is a memory leak. Also if the
> > function is tucked away in some library you have
> > to make an effort to
> > provide a way to use an alternative allocation function.
>
> Why does tucking it away in some library imply that you need to
> support an alternative allocation function? There may be (or may not)
> an issue for functions that are part of the standard library <OT>and
> kernel code may not be able to use malloc()</OT>, but in most cases
> there's no reason a library function can't use malloc().
>
> > 3. Pass an already allocated buffer and its size to your function.
> > Most
> > flexible but awkward,
> > especially if all you want is to print some quantity
> > in a special format.
> > Problem: Function must check buffer overflow and
> > signal error when buffer is too small.
>
> Actually, it seems to me that #2 is the most flexible technique. It
> allows the function itself to determine exactly how much memory it
> needs, and imposes minimal complexity on the call (apart from the need
> to free the allocated memory).

I'm partial to number 3.
Actually the called function doesn't have to do any checking or
signaling as long the programmer considers the onus to
be on the calling function to supply a buffer large enough.
With number 3 you can use any kind of object,
automatic, static or allocated.
If an allocated object is used, then it is allocated and freed
in the same function, which is good.

#include <limits.h>
#include <stddef.h>
#include <stdio.h>

#define E_TYPE unsigned char
#define P_TYPE unsigned
#define STRING " %s = 0x%x\n"
#define INITIAL 0
#define FINAL 0xf
#define OFFSET (sizeof(e_type) * CHAR_BIT - 4)
#define INC(E) (++(E))

typedef E_TYPE e_type;
typedef P_TYPE p_type;

void bitstr(char *str, const void *obj, size_t n);

int main(void)
{
e_type e;
char ebits[CHAR_BIT * sizeof e + 1];

puts("\n/* BEGIN output from bitstr.c */\n");
for (e = INITIAL; FINAL >= e; INC(e)) {
bitstr(ebits, &e, sizeof e);
printf(STRING, OFFSET + ebits, (p_type)e);
}
puts("\n/* END output from bitstr.c */");
return 0;
}

void bitstr(char *str, const void *obj, size_t n)
{
unsigned mask;
const unsigned char *byte = obj;

while (n-- != 0) {
mask = ((unsigned char)-1 >> 1) + 1;
do {
*str++ = (char)(mask & byte[n] ? '1' : '0');
mask >>= 1;
} while (mask != 0);
}
*str = '\0';
}

--
pete
.

Relevant Pages

  • Re: Library Design, f0dders nightmare.
    ... first demo mistake but I suggest to you that a sequence of blunders ... The stack is only used temporarily while creating the argv array. ... in the input buffer. ... so you are not wasting memory. ...
    (alt.lang.asm)
  • Re: Alternative to C for system programming
    ... be blocks of memory that are GC and nonGC, ... to call it a systems programming language with GC. ... Just make sure your disk buffer or whatever is ... allocation of memory: I/O module thinks it will need more memory ...
    (comp.programming)
  • Re: appending elements to an ALLOCATABLE array
    ... this feature would allow you to expand memory ... It is not a problem of allocation, ... In C this can be done using an array of pointers to dynamically ... Linked lists work very well for applications that address the data ...
    (comp.lang.fortran)
  • Re: callocs, call by ref and function returning in C
    ... > memory allocation and freeing). ... clobbering buffer, so you can never free that memory again. ... you exit without freeing up resources. ...
    (comp.programming)
  • Re: Attention Windows Users
    ... > how there could be a buffer overflow. ... > memory. ... A "dynamic allocation" is one that occurs at run-time. ... a buffer overflow can occur with either a dynamic or static ...
    (rec.aviation.piloting)
Loading