" sprintf(numbuf, "0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x",...)" . the formatted data wrote to "numbuf" is 39 bytes, but numbuf is 32 bytes.
This commit fixes nearly all of the reported doxygen warnings.
I tried to not clutter the log with removed trailing spaces.
Removed whitespace and converted tab/spaces for all files affected by this commit
are in a separate branch.
After page loading has finished the number of free bytes left for page attributes is logged. It turns out that "usual" pages tend to get along with ~800 bytes while i.e. the Google search pages use all of the 2000 bytes of page attribute memory allocated by default (because of the long URLs with many parameters). So it seems that reducing this default isn't exactly the best way to reduce memory consumption...
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
When the client has already called webclient_close() it doesn't expect to have webclient_datahandler(NULL, 0) called just because the connection was closed by the server "at the same time". Rather it expects to always have webclient_closed() called.
Calling webclient_datahandler(NULL, 0) instead of webclient_closed() means that the web browser shows "Done" in the status line instead of "Stopped". So the user is mislead to think that he has already seen all of the page.
Note: webclient_close() is called by the client during newdata() so the already existing check for WEBCLIENT_STATE_CLOSE further above doesn't help.
../..//apps/er-coap/er-coap-observe.c:237:15: warning: unused variable
‘content’ [-Wunused-variable]
This was caused by a buffer that was declared, but used only in
commented out code.
The variable was moved to the commented out block.
The block was surrounded by an #if 0 ... #endif to make it easier to
uncomment.
Everything still compiles with the code in question uncommented.
When a client sends a CoAP request with no block2 size,
the default one would be set to REST_MAX_CHUNK_SIZE.
However, this is not guaranteed to be a power of 2.
This can lead to clients receiving a bigger payload than expected as
part of the header, and ending up with duplicated content.
Setting the default to COAP_MAX_BLOCK_SIZE,
which is guaranteed to be a power of 2, fixes this.