Pointer Structure of Arrays?

I had a working code, such as the one below:

Code:

typedef struct { int* data } FIELD;
FIELD* pField;
fields;

allocint(int** i,j,k) {
*i = malloc(sizeof(int*));
...
}

...
realloc(pField,...);
allocint(&pField[fields].data,...);
...

Of course, I've cut most of the code. This method worked fine, but once there got to be about a thousand "realloc(pField,...);" calls, I started to get memory errors. So to fix that, I tried this sort of code:

Code:

typedef struct { int* data } FIELD;
FIELD* pField[MAX_FIELDS];
fields;

allocint(int** i,j,k) {
*i = malloc(sizeof(int*));
...
}

...
pFields[fields] = malloc(...);
allocint(&pField[fields]->data,...);
...

Now the program immediately has memory problems when calling allocint (It keeps saying that there is an error with "free()", but that isn't being used...)

I know that this problem has something to do with the &pField[fields]->data. I suppose that the function is not receiving an editable address of the data variable, but I haven't a clue on how to fix this. I barely understand how double pointers and the like work anyway.

I hope I didn't cut out so much of the code that it isn't clear what my intentions were. Thanks for your time!

And did you write allocint yourself? I was unable to find such a thing on either a man page or the MSDN site, so I know nothing about what the function is supposed to do, let alone whether it does it.

Yes. I wrote it as a shortcut to malloc or realloc depending on j and k. The actual code would have been inflated if I hadn't done the shortcut. Of course I cut out most of the function because I didn't think it was necessary to answer my question.

Sorry about the confusion!

Oh, sorry, I didn't realize that you actually gave the first line of the function in the snippet! Sorry.

As to free -- well, realloc calls free or something similar, more-or-less by definition. I'm guessing this means that somewhere (not in what was posted, apparently) you are clobbering your pointer, making it point somewhere else, and thus thwarting free/realloc in its task.

Well, that's what I thought, but when I removed the "realloc" from the function, it still came up with the same "free()" error. I didn't bother with any other functions (which have the same task, but with different inputs) because they were never being called by the time the program crashed.

Well, if you have an error with free, then something's causing it. At this point, you'll probably want to break out the debugger and step through to see where you are when bad things happen, or at least get a stack trace.

I see a few strange things here. Why do this:

Code:

typedef struct { int* data } FIELD;

when you can do this

Code:

typedef int* FIELD;

Because you like typing x->data? Then, by your own admission:

Originally Posted by Heathtech

I barely understand how double pointers and the like work anyway.

Hopefully there is a real lifeguard around, but I don't think you need or should be using one here. Which could lead to the realloc problem tabstop describes.

Okay. I'm no good at figuring out stack traces, but I will try to figure out a work around.

Just as a last question, do you think that the &pField[fields]->data is being called correctly? It should have the same result as the first code, but this time from within a FIELD* pField[...], versus a FIELD* pField.

MK27:
There is actually a lot more data within the structure, not just the int*.

Originally Posted by Heathtech

MK27:
There is actually a lot more data within the structure, not just the int*.

Fair enough. But I still don't get how it becomes a pointer to a pointer for allocint. x->data is a pointer to an int.

I need that function to set the data variable to the address provided by malloc. I don't think that's possible if you don't pass it as a pointer... Maybe I misunderstood your comment.

Originally Posted by MK27

Fair enough. But I still don't get how it becomes a pointer to a pointer for allocint. x->data is a pointer to an int.

And therefore &x->data is a ....

Originally Posted by heathtech

Okay. I'm no good at figuring out stack traces, but I will try to figure out a work around.

No time like the present to learn. I can't really help, since you seem unwilling or unable to provide any information about what's going on.

I don't want to post more than is necessary to ask the question... Since there is still confusion of the purpose of the function, I will post the rest of the code:

Code:

int allocint(int** i,int j,int k) {
	if(x==0) *i = malloc(sizeof(int));
	else *i = realloc(*i,sizeof(int)*(j+1));
	if(*i==NULL) return -3;
	(*i)[j] = k;
}

//Somewhere else in the main program...
allocint(&pField[fields]->data,counter++,otherdata);

"counter" is not necessarily a local variable and "otherdata" is read from a file.

Maybe this will help clear it up? I just want to know why the &pField[fields].data worked in the first example and now the one above apparently doesn't work. I know that this is the offending function thanks to variously placed printf() statements.

So why not if (j==0) *i = etc.?

Originally Posted by tabstop

Originally Posted by Originally Posted by MK27

Fair enough. But I still don't get how it becomes a pointer to a pointer for allocint. x->data is a pointer to an int

And therefore &x->data is a ....

What do you expect whatever->data to be? an array of ints? Or the literal value of a memory location (0xdeadbeef) that you are going to use how?