Yet another nested structure problem (concept phase)

[bitstreamer]

Greetings.

The emulation fever has conquered all kinds of Internet communities, and hence I've decided to write a tool in C which can read and modify a disk image.
(However, I won't tell which kind of disk images until it's finished.

Only problem I have now, where do I start and where do I have to malloc() and where not? It's better to know about this in the concept phase, for when the tool goes beyond the magical 1000-lines extent, it will be near impossible to figure out why the thing GPFs.

Given: disk image, 1024 disk blocks, one block holds 256 bytes of data.
Each byte, word or long word must be accessible directly.

Draft follows.
As you can see, I've decided to be EXTREMELY verbose because there might be other people who sometimes struggle with these large structure concepts.

typedef struct singleBlk {
unsigned char block_data [256];
char * strInLW [256 / 4]; /* string in longword, single-lw */
char * multiStr; /* string that spans several longwords in a seq;
cannot be longer than bytes per block */
} singleBlkS_t;

typedef struct dskImg {
singleBlk_t * dskBlk [1024];
} dskImgS_t;

int main(void)
{
dskImgS_t img; /* allocate mem for 1024 _pointers_ */
dskImgS_t * imgptr = &img; /* ptr to large structure */

buildImgS(imgpt r);
}

void buildImgS (dskImgS_t * pImg)
{
int i;
for (i = 0; i < 1024; i++)
{
/* next line reserves mem for:
1) 1 sub-structure, singleBlk_t, itself
2) 256 bytes of block buffer, block_data
3) 64 char* _pointers_ per block, strInLW
4) 1 char* _pointer_ per block, multiStr
*/

pImg>dskBlk[i] = malloc (256* sizeof (singleBlk_t));

/* now the rest pointed at by ptrs must be allocated too (!) */

for (j = 0; j < 256; j++)
pImg>dskBlk[i]->strInLW[j] = malloc (64 * sizeof(char));

pImg>dskBlk[i]->multiStr = malloc (256 * sizeof(char));
}
}

Phewww...
Now I ask you guys:

Can this be safely simplified a bit, and if so, how?
I think I could get rid of the for() loops, however, this is always dangerous because from my experience, it's damn easy to make mistakes in multiplying the sizeof() things.
Moreover, I'm not quite sure how to write this when I omit the [index].

Well, I'd appreciate any suggestions, criticism, bashing, ... *g*

[bitstreamer]

please, does anyone have any ideas for me? o_O

[JosAH]

In your description you mention that a single disk block contains 256 bytes only
but in your structure definition it contains 256 bytes and 64 pointers and another
pointer. Why? What are all those char pointers doing there?

kind regards,

Jos

[arnaudk]

Just a few additional points

• Why do you need both img and imgptr? It would be simpler to just use one of them.
• You can omit the for loops by allocating all the memory in one go, for example: pImg->dskBlk = (singleBlk_t **) malloc (1024*256* sizeof (singleBlk_t));
• You don't have an explicit declaration of buildImgS() before you use it in main(): some compilers may complain (maybe you've omitted it here for illustrative purposes).
• There are some typos like ">" instead of "->", your main should have a return value etc. I could quote line numbers if you had used code tags.

[Banfa]

In singleBlkS_t assuming that you need all those char arrays (and there is not a good reason why they have to be pointers) then declare the array in the structure rather than a pointer. Then you can just allocate singleBlkS_t without having to have the nested loop allocating all those char arrays as well.

Then in dskImgS_t rather than declaring an array of pointers declare a pointer to an array

singleBlk_t (*dskBlk) [1024];

then just malloc a big single block of memory 1024 * sizeof(singleBl kS_t) long to assign to it.

Doing both these will remove both loops and result in a single call to malloc.

1 issue with that may be that you system does not like the sear size of the block you are trying to allocate, in this case only do the first of my 2 suggestions.

[Banfa]

Hmmm ignore my second suggestion I missed the allocating an array of 256 structures to each pointer in the top level structure.

Given that you are allocating over 1GB of data I would probably suggest not allocating it in 1 big chunk but continue allocating 1024 chunks of just over 1MB.