@@ -88,17 +88,18 @@ _Ref 11.1.1_
8888
8989_ Ref 11.3.1_
9090
91- - MISRA C-2012 Rule 11.3 The data received/sent by the IP stack is represent as
92- a byte stream. This byte stream needs to be casted to various data structures
93- to access certain fields of the packet. However, when casting a byte stream to
94- a structure, MISRA warns us that it can lead to unaligned access. But, in case
95- of FreeRTOS+TCP, the buffer in which the packets are stored are always aligned
96- to a 4 byte word boundary with an offset of 2 bytes. The reason for this 2
97- byte offset is that the ethernet header is of 14 (12 + 2) bytes. Thus,
98- everything except the ethernet header is properly aligned. There is one
99- alignment exception, which is the sender protocol address in the ARP Header.
100- To combat that, the sender protocol address field is declared as an array of 4
101- bytes instead of a ` uint32_t ` . More details can be found
91+ - MISRA C-2012 Rule 11.3 The data received/sent by the IP stack is represented
92+ as a byte stream. This byte stream needs to be casted to various data
93+ structures to access certain fields of the packet. However, when casting a
94+ byte stream to a structure, MISRA warns us that it can lead to unaligned
95+ access. But, in case of FreeRTOS+TCP, the buffer in which the packets are
96+ stored are always aligned to a 4 byte word boundary with an offset of 2
97+ bytes. The reason for this 2byte offset is that the ethernet header is of
98+ 14 (12 + 2) bytes. Thus,everything except the ethernet header is properly
99+ aligned. There is one alignment exception, which is the sender protocol
100+ address in the ARP Header. To combat that, the sender protocol address field
101+ is declared as an array of 4 bytes instead of a ` uint32_t ` . More details can
102+ be found
102103 [ here] ( https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/pull/512#pullrequestreview-1035211706 ) .
103104
104105#### Rule 11.4
0 commit comments