Re: OT: Language War (Re: "C" Manual)

[Eric G.Miller <egm2@jps.net>]

On Sun, 6 Jan 2002 16:48:31 -0500 (EST), William T Wilson <fluffy@snurgle.org> wrote:

> On Sat, 5 Jan 2002, Eric G.Miller wrote:
> 
> > is one of the reasons pointers to char are so common.  However, there
> > is a little trick that's guaranteed to always work:
> > 
> >  struct foo {
> > 	size_t length;
> > 	char str[1];
> >  };
> > 
> >  ...
> > 
> > struct foo * str_to_foo(char *a)
> > {
> >   size_t len = strlen (a);
> >   struct foo *bar = malloc (sizeof(struct foo) + len);
> >   if (bar) {
> >     bar->length = len;
> >     memcpy (bar->str, a, len);  /* bar->str now not NUL terminated */
> >   }
> >   return bar;
> > } 
> 
> It doesn't look particularly guaranteed to me.  You're really allocating
> *three* pieces of memory here - one for the struct foo, one for the
> 1-character array chr, and one for the rest of the string.  Your example
> assumes that chr will be located in memory immediately after foo - which
> it probably will, but it might not.  It could be anywhere, the language
> makes no guarantee.  The compiler might even choose to put the 1-char
> array before foo, so you can't use it without overwriting your struct

It *is* one chunk of memory, and it does work. The compiler is not allowed
to reorder the members of the struct.  A pointer to the struct is always
guaranteed to be a pointer to the first element, as well.  The compiler
may add padding between elements of the struct for alignment purposes,
but we don't need to care about that (sizeof(struct foo)) will do the
right thing.  If you don't believe me, ask the guru's on comp.lang.c.
This extra space allocation for structs trick, only works for the last
member of the struct (obviously), and it should be declared as an
array with one element (it's not limited to char's).

> Structs have fields.  Use them.

I thought I was.

> > The benefit is being able to use one malloc vs. two (for any similarly
> 
> This is a benefit why? :}

Calls to malloc are relatively expensive.  It's more efficient to use
fewer large allocations than many small ones.  Also, makes management
of the memory a little simpler (only one chunk of memory to worry about).


-- 
Eric G. Miller <egm2@jps.net>