-->
Page 5 of 13

Re: Possible replacement MQTT library

PostPosted: Fri Aug 28, 2020 12:51 pm
by pangolin
I'm also fed up with repeating myself to people who dont read the documentation and insist on using the wrong calls then complaining when they "don't work"
1. Pangolin provides raw uint8_t* and length function which is 100%-compatible with every other MQTT library, so your assertion is fundamentally incorrect and easily proven so simply by looking at the API
2. If you use the above , then like all other implmentations, no trailing \0 is stored - thats coding 101. So, if you then use a specific call which requires there to be a trailing zero (like every C string function) then of course it won't work! So don't do that - unpack the payload yourself using the correctly provded length, as in any other fully compatible implementation
3. If you call client.publish("mytopic",qos,retain,payload); where payload is eiter a std::string or a String then Pangolin appends a trailing \0 so that the payload can be used by any "normal" string function - including of course payloadToCstring. If this is not what you want then don't use it! use method 1 which works the same as any other MQTT implemntation.
4. Please , don't mix and match functions that were never intended to work together and then complain - wrongly - that they don't work and then "badmouth" the product - incorrectly - because you either didn't read or don't understand the documenation.

Re: Possible replacement MQTT library

PostPosted: Sat Aug 29, 2020 3:01 am
by Pablo2048
Ok, so lets say it at full mouth: There is no technical reason for such stupid string encoding. Relying on /0 terminator from unknown source made all applications using PangolinMQTT PANGO:payloadToCString() and/or PANGO:payloadToInt() vulnerable to (some sort of) DoS buffer overflow attacks just for free, no matter how much documentation you have read. I definitely don't follow why are you still standing at your point holding this obscure, incompatible and dangerous transport form, and this is my last response about this...

Re: Possible replacement MQTT library

PostPosted: Sat Aug 29, 2020 12:39 pm
by eriksl
Pablo2048 wrote:I use ESP.getHeapFragmentation(), ESP.getFreeHeap() and ESP.getMaxFreeBlockSize() to monitor the memory allocation. Also I'm doing (at least try to do...) all dynamic allocation at startup and avoid runtime dynamic heap allocation other than internal network buffers. It's not MISRA compliant, but it is close enough to allow 24/7 runtime for my application.

What development environment, this looks like Arduino?

Re: Possible replacement MQTT library

PostPosted: Sat Aug 29, 2020 12:40 pm
by eriksl
davydnorris wrote:
eriksl wrote:How do you guys check how much RAM you actually have left?

I use system_print_meminfo() and system_get_free_heap_size()

Yes, that has the drawback that it doesn't include the dynamic memory use of lwip (unless you configured lwip yourself to have everything static - I did).