Re: Segmentation fault!

Paminu wrote:
[snippage]
typedef struct _node_t {
int num_kids;
void *content;
struct _node_t **kids; // Makes a pointer to a pointer of node_ts.
} node_t;

Since no one else has mentioned it yet, it is wise to avoid leading
underscores on names (unless you are the guy writing the compiler
in the first place, in which case it is wise to prefer leading
underscores on names -- the goal here is to keep the programmer's
names, which never start with underscore, from accidentally colliding
with the implementor's names, which always start with underscore).
It is also best to write the typedefs *before* defining the
structures, if you are going to use typedefs at all, because --
well, you will see in a moment:

typedef struct node_t node_t; /* this comes first ... */

struct node_t {
int num_kids;
void *content;
node_t **kids; /* ... because then you can use it here! */
};

(My own preferred method is to omit the "typedef" entirely, and
just write out "struct" as needed.)

In any case, avoid the leading underscore -- the implementor is
using those names!

In article <43ee3586$1@xxxxxxxxxxxx>
Rod Pemberton <do_not_have@xxxxxxxxxxxxxxxxxxx> wrote:

(Hm, which one is it, ".cmm" or ".com"?)

*** kids is an array of pointers to _node_t, correct?

Well, "to be used as" -- as it stands, it is a pointer, which can
point to zero or more objects of type "pointer to struct _node_t".
("struct _node_t" is the real name, "node_t" is just an alias
that allows omitting the seven characters "struct ".)

Wouldn't kids be better defined like so:
struct _node_t *(kids[]);

This is a C99 feature: a structure that ends with a member of type
"array of T" (for some valid data type T), with no size, creates
a struct type with a "flexible array member". While C99-conformant
compilers are becoming more common, in my opinion they are not yet
common enough to recommend regular use of C99 features. Still,
this is a reasonable thing to do if you have C99 compilers. This
gives:

struct node_t {
int num_kids;
void *content;
node_t *kids[]; /* C99 flexible array member; must be last */
};

i.e., the parenthese are unnecessary. Using the flexible array
member will save one malloc() call.

node_t *node_alloc(void *content, int num)
{
node_t *parent;
parent = malloc(sizeof(node_t));

"Vladimir S. Oka" <novine@xxxxxxxxxxxxxxx> wrote in message
news:dskqvf$bc1$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You should test whether malloc() returns NULL.

Indeed.

Using the flexible array member method, you must add to the
size requested here. You will want enough storage for *parent
(a "node_t", so either "sizeof *parent" or "sizeof(node_t)" will
work) *plus* enough storage for "num" pointers to "node_t":

parent = malloc(sizeof *parent + num * sizeof *(parent->kids));
/*
* or, equivalently:
parent = malloc(sizeof(node_t) + num * sizeof(node_t *));
*
* Note that the parentheses around parent->kids are actually
* redundant, so you could write:
parent = malloc(sizeof *parent + num * sizeof *parent->kids);
*/

parent->content = content;
parent->num_kids = num;

These lines are fine.

node_t *new_kids[num];

This line also uses a C99 feature, or in fact, *two* C99 features:
"declaration anywhere" and "variable length array". This creates
an automatic-storage-duration array, "new_kids", of size "num", with
elements of type "pointer to struct node_t".

Because this array has automatic storage duration, it will vanish
when the function returns (as Vladimir Oka notes later).

int i;

And this also uses the C99 "declaration anywhere" feature.

*** He's changing the type of content from 'const char *' to 'void *'.

If all the quoting is accurate, this is not the case in the code
fragment shown, at least. The parameter to the function is "void *"
and the member named parent is "void *"; there are no "const char *"s
to be seen.

(I do not have access to the entire original code, only the parts
quoted in the article to which this is a followup.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
.

Relevant Pages