Fix for bit ordering of li, vn, and mode

[ProudGecko]

The original bit order was wrong for the first byte of the NTP packet. For example, settings ntp[0] = 0x1C, results in li = 0, vn = 7, mode = 0. The correct answers are li = 0, vn = 3, mode = 4.

Here's a screenshot of the visual studio debugger showing the issue.

[lettier]

Hello @ProudGecko and thank you for your contribution.

The order of bit fields within a unit is implementation-defined. For your particular implementation, the order appears to be low-order to high-order hence why rearranging the order to mode, vn, and li outputs the correct values on your machine. Since it is implementation-defined, it could be low-order to high-order, vice versa, or something else.

Ultimately the order over the wire is big endian with the li, vn, and mode byte being from high-order to low-order.

If we cared about the individual fields in the li, vn, and mode byte it would be better to use uint8_t li_vn_mode;, use bitwise operators, and remove all of the bit fields.

Since we do not bother with these particular fields individually, we will keep their order as-is in the interest of clarity by following the RFC for the purposes of the article.

👍

High-Order to Low-Order

>>>>>>>>>>>>>>>
00 | 011 |  011
---------------
 0 |   3 |    3
---------------
li |  vn | mode
---------------

Low-Order to High-Order

>>>>>>>>>>>>>>>
11 | 011 |  000
---------------
 3 |   6 |    0
---------------
li |  vn | mode
---------------

or

<<<<<<<<<<<<<<<
 000 | 110 | 11
---------------
   0 |   6 |  3
---------------
mode |  vn | li
---------------

[ProudGecko]

That's true about implementation specific endianness; however, you've included a C structure definition that assumes a big-endian architecture even though it appears you've built and run this sample on an x86 machine. At the least a comment in the structure would be useful for others that may scratch there head over this.

Thanks for your response!
David