RIFF RIFF/LIST header structure? Actual data overlap with header fccType?

[superfury]

According to:
http://www.johnloomis.org/cpe102/asgn/asgn1/riff.html

The RIFF and LIST headers are like this:

typedef struct { 
     FOURCC ckID; 
     DWORD ckSize; 
     union { 
          FOURCC fccType;          // RIFF form type 
          BYTE ckData[ckSize]; 
     } ckData; 
} RIFFCK;

Shouldn't this be:

typedef struct { 
     FOURCC ckID; 
     DWORD ckSize; 
     FOURCC fccType;          // RIFF form type 
     BYTE ckData[ckSize]; 
} RIFFCK;

Are the first four bytes of the ckData[ckSize] used for fccType, or does the full ckData[ckSize] go after the fccType?

So (what it's according to me):

BYTE INDEX - Data
0 - R
1 - I
2 - F
3 - F
4 - 4 <-- We have 4 data bytes
5 - 0
6 - 0
7 - 0
8 - S
9 - F
A - B
B - K
C - Data byte 1
D - Data byte 2
E - Data byte 3
F - Final data byte of the RIFF entry

Or (according to the specs):

BYTE INDEX - Data
0 - R
1 - I
2 - F
3 - F
4 - 8 <-- We have 4 data bytes, plus the fccType data bytes.
5 - 0
6 - 0
7 - 0
8 - S
9 - F
A - B
B - K
C - Data byte 1
D - Data byte 2
E - Data byte 3
F - Final data byte of the RIFF entry

According to the data on the above link, any values less than 4 in the ckSize would be illegal with a RIFF/LIST chunk?

[dhayden]

It looks to me like ckSize is the number of bytes that follow the ckSize field. For RIFF and LIST chunks, the first 4 bytes are the fccType. So I think the union is appropriate.

[superfury]

But isn't the fccType actually a part of the header instead of the data? So when reading and detecting a RIFF/LIST entry using my method, and substract 4 bytes from the data part (after word alignment).

So:

typedef struct { 
     FOURCC ckID; 
     DWORD ckSize; 
     FOURCC fccType;          // RIFF form type 
     BYTE ckData[ckSize-4]; //The actual data
} RIFFCK;

Also does ckSize need to be word aligned before processing?

[dhayden]

But isn't the fccType actually a part of the header instead of the data?

It depends on what you consider the data and what you consider the header. I think the point is that the ckSize field give the number of bytes that follow that field. Within those bytes there is structure defined by the FormType, and so on and so on.

This sort of thing is common. You get a blob of data that has a header and some payload. Within the payload, there is another header and another piece of payload, and so on. You can represent it the way they've shown or the way you have it, both are equivalent.