How to prevent the compiler messing with a structures allignment

[Nominal Animal]

Did you allow for chunks not in a fixed order?

Sure, the order is often semi-arbitrary.  For example, PNG files have an 8-byte fixed header, the first chunk is IHDR, the last chunk is IEND, but otherwise the chunk order may vary.  IDAT chunks contain the image data, and can be split into two or more, it does not need to be a single chunk; the order of the IDAT chunks with respect to each other must be retained, however.

That is, the order of different types of chunks is often arbitrary, but the order of the same specific type of chunk must be retained; and often one or two initial and sometimes a final chunk are mandatory.

In fact, we could consider TCP (TCPv4 AKA TCP over IPv4, or TCPv6 AKA TCP over IPv6) protocol a chunked format, with their sequence number indicating the position in the stream.  Even URGent TCP data is just a 16-bit offset into the packet payload (indicating the end of normal data and the start of URGent data), although TCP stack implementations (are supposed to) treat it as out-of-band data.

text is defined by terminators and I think that's probably more robust than having the expected length noted before the actual data.

Like gps nmea

Yes, NMEA GPS is a stream format, where $ is the separator (or new message begin marker), and comma , a field separator marker, and asterisk * the checksum-follows marker for each message.

It does not matter that much that each field is technically human-readable; most of the data is numeric, and could be nibble-encoded or even floating-point data, but those would be even more work to parse!  The only downside is the relative low density storage for the numbers, but as the messages are quite short and the report interval is in the human scale (as opposed to say thousands of times per second), it does not matter when using typical current standard serial transport methods (as they have plenty of bandwidth for this).

Edit: Not all text formats are stream formats, though.  There are fixed-number-of-columns text formats, as well as text-based netstring-like encodings.  And of course there are oddball variants between the four classes I showed, TCP in particular, where earlier bits in each chunk can modify the format of the current chunk (header fields).  So it isn't a perfect classification system by any means, but it is more useful than "text" versus "binary".

[nctnico]

Note that if the CAN bus message order cannot be absolutely controlled, you can use N times the number of CAN bus identifiers

If you have dedicated CAN IDs per producer / consumer pair, then the order of the CAN messages is perfectly controllable. Many CAN controllers also have multiple transmit and receive queues so a whole bunch of stream oriented CAN messages don't get in the way of higher priority CAN status broadcasts. But you'll still need to add something to the stream protocol that can detect missing / lost CAN packets.

[julian1]

I am using bitfields in a packed struct,

Gcc gives the following 'note' (not warning or error) related to a change between old compiler versions,

    In file included from myfile.c:nn:
   ./myheader.h:nnn:n: note: offset of packed bit-field 'myfield' has changed in GCC 4.4


Is there a way target/turnoff/suppress the 'note' with a pragma (preferred) or flag?
Normally warnings can be handled with -W and -Wno flags etc,  but I have not seen 'note' used as a reporting method before.

[Nominal Animal]

    In file included from myfile.c:nn:
   ./myheader.h:nnn:n: note: offset of packed bit-field 'myfield' has changed in GCC 4.4
Is there a way target/turnoff/suppress the 'note' with a pragma (preferred) or flag?

Yes: use -Wno-packed-bitfield-compat.

[julian1]

Thanks Nominal Animal. That works great.