Struct array size

Hi

I have a Struct that contains a number of values, one of these values is an array that I want to define the size of later in my application.

Code:

---

typedef struct
{
uint8_t          address;
uint8_t          rxAddress;
uint8_t          type;
uint8_t          payload[54];  // <- This one here
} PACK packet_t;

---

It can be one of two sizes, either 54 (as shown above) or 9, and I cannot work out a way to allocate it during the init of my application. I have tried using malloc to allocate the space needed, it does not complain however I don’t believe the size is correct as when I set it to 56 I get array overflows...

Has anyone got any clever ideas?

thanks

David

Code:

---

typedef struct
{
uint8_t          address;
uint8_t          rxAddress;
uint8_t          type;
uint8_t          payload[1];  // <- This one here
} PACK packet_t;

---

The above definition [note 54 changed to 1] and the following:

Code:

---

packet_t *allocatePacket(bool has54payload)
{
  packet_t *pkt;
  size_t size = 9;
  if (has54payload) size = 54;
  pkt = malloc(sizeof(packet_t) + size - 1);  // -1 because we already have 1 element in the struct.
  return pkt;
}

---

Some compilers support

Code:

---

    ...
    uint8_t          payload[0];
    ...

---

In which case you could remove the -1 in the malloc() call.

--
Mats

Quote:

---

Originally Posted by matsp

Code:

---

typedef struct
{
uint8_t          address;
uint8_t          rxAddress;
uint8_t          type;
uint8_t          payload[1];  // <- This one here
} PACK packet_t;

---

The above definition [note 54 changed to 1] and the following:

Code:

---

packet_t *allocatePacket(bool has54payload)
{
  packet_t *pkt;
  size_t size = 9;
  if (has54payload) size = 54;
  pkt = malloc(sizeof(packet_t) + size - 1);  // -1 because we already have 1 element in the struct.
  return pkt;
}

---

Some compilers support

Code:

---

    ...
    uint8_t          payload[0];
    ...

---

In which case you could remove the -1 in the malloc() call.

--
Mats

---

That's damn clever. I'm impressed :D

Quote:

---

Originally Posted by Kernel Sanders

That's damn clever. I'm impressed :D

---

I must admit that I didn't invent that method - it was used in OSE when I started working for Enea Data in the early 1990's. And it's a fairly standard pattern (I have seen it several places since then). It works as long as the packet ENDS with the variable part. Otherwise it's much harder to solve.

--
Mats

wow - thank you :)

Quote:

---

Originally Posted by matsp

I must admit that I didn't invent that method - it was used in OSE when I started working for Enea Data in the early 1990's. And it's a fairly standard pattern (I have seen it several places since then). It works as long as the packet ENDS with the variable part. Otherwise it's much harder to solve.

--
Mats

---

Now, I'm impressed :D

Out of curiosity is there any particular reason why you would use:

Code:

---

uint8_t payload[1];

---

instead of

Code:

---

uint8_t* payload;

---

?

Quote:

---

Originally Posted by mike_g

Out of curiosity is there any particular reason why you would use:

Code:

---

uint8_t payload[1];

---

instead of

Code:

---

uint8_t* payload;

---

?

---

Because that's then not part of the SAME chunk of memory - the payload would be a pointer to another piece of memory, which means that the sending routine would have to keep track of the size of the header and the packet itself in separate sections. Many times, you want ONE lump of memory to send [particularly for the low-level driver that doesn't even care about the protocol - you just package up some data into a packet and send it to the low-level driver that sends the whole thing - if you have multiple chunks of memory, the low-level driver must have a list of different items to transmit. Makes the driver a bit more complex].

Edit: Also, having two different parts of memory makes the receiving end more complex, as the low-level driver will have to call malloc (or similar) twice rather than once for the packet.

--
Mats

Oh I see, thanks.

It's such a useful technique that is has been blessed by C99
http://www.comeaucomputing.com/techt...flexiblearrays