|Re: [paho-dev] MQTT-SN and MQTT embedded C client updates|
1) To limit the values that can be passed into the functions to valid ranges, such as 0 to 64k for packet ids. Generally, using data types for this is only an approximation.
2) To ensure that data of a predictable size is returned from the deserialize functions, like 1 byte for the boolean flags.
Ian On 08/02/2014 05:43 PM, Frank Pagliughi wrote:
On 08/02/2014 06:08 AM, Ian Craggs wrote:Packet ids have been changed to "unsigned short", and data buffers to "unsigned char". Now the data types are also consistent between the MQTT and MQTT-SN libraries, which was another motivation.Is there a reason why you wouldn't use the C99 sized types (uint16_t, int32_t, etc) from <stdint.h>? Most compilers support them now - even for embedded chips - and it reduces the headaches for portability. If a particular compiler/platform doesn't have them, it's easy to define them for that compiler.I'm not expecting any further data type changes unless a good reason appears. I started using size_t for buffer sizes, but have stuck with ints to reduce dependencies on any headers - just in case some esoteric/old embedded compiler didn't like size_t.I would suggest trying to make the 'size_t' work. A lot of compilers/platforms have different sizes for 'int' and 'size_t'. The 'int' type is (normally) the native register size whereas 'size_t' is supposed to be the addressable memory space. So 'size_t' can be a larger type than 'int'. On the GCC x86_64, 'int' is 32-bits whereas 'size_t' is 64-bits. On some 16-mit microcontrollers, 'int' is 16-bits, whereas 'size_t' is 32-bits.So if you use 'int' as an array index you might not be able to express the actual length of an MQTT packet on smaller platforms.Frank _______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
-- Ian Craggs icraggs@xxxxxxxxxx IBM United Kingdom Committer on Paho, Mosquitto
Back to the top