nanocoap_sock: defuse nanocoap_sock_get() API footgun

[benpicco]

Contribution description

nanocoap_sock_get() would use the supplied response buffer to assemble the request header.
While this can be an efficient use of space, it's also really surprising for users who only expect to receive a small payload and have the request fail (actually corrupt the stack because nanoCoAP only checks if a buffer overflowed after it has written to it).

All other nanocoap_sock_*() functions use a small stack based buffer for the header - let's do the same for nanocoap_sock_get() to avoid nasty surprises.

Testing procedure

Issues/PRs references

[kaspar030]

ACK.

[chrysn]

I was about to complain about this getting into gcoap's area of resource usage (gcoap's stack is one frequent point of complaints) ... but given I see @kaspar030 as the defendant of nanocoap's slimness and he's fine with it, go :-)

[kaspar030]

Heh, now that you said that, I actually confirmed that CONFIG_NANOCOAP_BLOCK_HEADER_MAX can't be that much. :)

❯ git grep "define CONFIG_NANOCOAP_BLOCK_HEADER_MAX"
sys/include/net/nanocoap.h:#define CONFIG_NANOCOAP_BLOCK_HEADER_MAX   (80)

[riot-ci]

Murdock results

✔️ PASSED

f6f5b13 nanocoap_sock: don't use return buffer for request

Success	Failures	Total	Runtime
6930	0	6931	09m:35s

Artifacts

• Documentation preview

[benpicco]

bors merge

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Murdock
• static-tests
• tools-build-success