Question about accessing fields in Notecard response

Notecard API
1

Hello
I have questions about the C code used to access Notecard response:

The example code below is given (in the Arduino library documentation) for retrieving data from the “card.status” request:

char status[20];
if (J *req = notecard.newRequest("card.status")) {
    J *rsp = notecard.requestAndResponse(req);
    notecard.logDebug(JConvertToJSONString(rsp));

    bool connected = JGetBool(rsp, "connected");
    char *tempStatus = JGetString(rsp, "status");
    strlcpy(status, tempStatus, sizeof(status));
    int storage = JGetInt(rsp, "storage");
    int time = JGetInt(rsp, "time");
    bool cell = JGetBool(rsp, "cell");

    notecard.deleteResponse(rsp);
}

I have two questions:

  1. in the line char *tempStatus = JGetString(rsp, "status");
    Since *tempStatus is simply a pointer to the start of a memory area which is going to be overwritten by JGetString( … ), what stops this overwriting other data which may be in memory after the *tempStatus location?

  2. The line strlcpy(status, tempStatus, sizeof(status)); is meant to write the data starting at “tempStatus”, to the location starting at “status”, for "sizeof(status) bytes.
    Shouldn’t it be “sizeof(tempStatus)” instead of “siizeof(status)”?

Thanks
Gary

2

Hi @GaryQ and welcome to the Blues forum!

I love that you’ve been looking through the implementation and trying to find areas to improve; this is the beauty of open-source software!

  1. Nothing. You are able to corrupt the response you requested from the Notecard if you so choose.

    Admittedly, this is not ideal, and an excellent observation. I agree it would be nice to get a compiler warning if you were about to modify the result, because it is unlikely that would be your intention.
    IIRC, the response buffer is provided exclusively for the user application (and is not consumed by the library), so there is a limited scope to any side-effects from making such a mistake. We are currently investigating the scope of changing this function result, and a handful of other results, over to a const char *, as you have suggested.

  2. No. The size of the buffer is more important, because we could accidentally create a non-NUL-terminated string without it.

    From the strlcpy() man page:

    … strlcpy() and strlcat() take the full size of the buffer (not just the length) and guarantee to NUL-terminate the result (as long as size is larger than 0 or, in the case of strlcat(), as long as there is at least one byte free in dst ). Note that a byte for the NUL should be included in size . Also note that strlcpy() and strlcat() only operate on true ‘‘C’’ strings. This means that for strlcpy() src must be NUL-terminated …

    strlcpy(3) - Linux man page

Sorry for the delay in responding, your message somehow slipped through the cracks. I really do appreciate the thoughtfulness of this post, and we ALWAYS welcome questions and suggestions for improvement like yours!

Sincerely,
Zak