Also, what is the value of returning only the length of the resource list without also providing the content?

It also should be straightforward to write a unit test for this new function since no packet exchange is required.

what is the value of returning only the length of the resource list without also providing the content?

The idea was to be able to find out the length of the resulting string so one can allocate/provide a sufficient buffer later (same principle as applied for the fmt module). But looking at this now, I think this makes only limited this context, so I tend to remove this 'feature' for simplification.

It also should be straightforward to write a unit test for this new function since no packet exchange is required.

Didn't seem that simple to me, though I have not really looked into it more than 30s... Will look some seconds more and see what I can do :-)

added unittests

Thanks for the unit test and the rationale on returning only the length of the contents. The more I think about this function, it seems valuable to ensure a client can retrieve the entire list. I wonder if it would be more useful to recast it like this:

int gcoap_print_resource(void *buf, size_t maxlen, unsigned index, uint8_t cf)

where index is into the list of resources. This way buf doesn't need to be so big, and the client is guaranteed to be able to increment through all of the resources. The function can return some flag value like GCOAP_END_OF_RESOURCES when done.

This approach would mesh well with CoAP block support for a /.well-known/core request.

I have been thinking the same, but came to the conclusion that I wanted to keep the function straight forward in the first round and add this 'advanced' buffer handling later. I actually expect this function to change/advance anyway in the near future, as I am looking into ways to specify more context information about the resources (e.g. d, et, ct, ...). My current thought is to add one additional function for each resource, that returns the context information for that resource in some way. This will be especially useful when looking in the direction of wildcards for resource paths... This could lead to something like

void gcoap_init_reslist(gcoap_reslist_ctx_t *ctx, size_t blocksize, unsigned block_num, uint8_t cf);
int gcoap_read_reslist(gcoap_reslist_ctx-t *ctx, void *buf);

But anyway: I would like to put this on the (ever growing) 'lets-improve-later' list if that is alright with you.

Sounds good. ACK on this PR.

awesome.

Fixed typo in doxygen and squashed -> Murdock should be happy now.