_processUrcPacket manipulate string in function scope

[chinglee-iot]

This PR is related issue #130.

• Remove the urcParseToken function. Manipulate allocated string in function scope in _processUrcPacket only.
• Use different variable name for different URC pattern to help reader understanding the handling flow.
  • URC with prefix : _atParseGetHandler( pContext, pTokenPtr, pSavePtr );
    pInputLine will be splited into the following format
    pIntputLine = "+" pTokenPtr + " : " + pSavePtr
    pTokenPtr is used to search URC handler with prefix and pSavePtr is the input parameter to the URC handler.
  • URC without prefix : _atParseGetHandler( pContext, pInputLine, pInputLine );
    pInputLine will be used to search URC handler and pInputLine will also be used as input parameter to the URC handler.
  • URC handler not found : _Cellular_GenericCallback( pContext, pInputLine );
    CellularUrcGenericCallback_t will be called. pInputLine is the input parameter to the function.

[tpecar-ltek]

Still retains the issue described in #130

Suggesting the following implementation

        /* Move pTokenPtr to URC name start */
        pSavePtr = pInputLine + 1
        pTokenPtr = pSavePtr;

        /* Scan for : or string end */
        while ( *pSavePtr != ':' && *pSavePtr != 0 )
            pSavePtr++;

        /* Null terminate pTokenPtr and move pSavePtr to URC content start */
        if ( *pSavePtr != 0 )
            *( pSavePtr++ ) = 0;

It is not a direct equivalent (strtok skips multiple consecutive delimiters), but this isn't relevant for our use case.

[chinglee-iot]

Thank you for your feedback.
I probably misunderstand your original suggestion.
Are you suggesting that not to use strtok_r and manipulate the string in this function directly?

[tpecar-ltek]

Yes, the reason being that AFAIK the typical standard library implementations (or at least their man pages) do not guarantee what savePtr (usually named lasts) should be, other than vaguely describing that it stores the required state. Some man pages describe it to be internal to strtok_r.

However, I have to admit that I did not check if contemporary implementations actually differ.

Either case it is an opaque piece of code that I viewed often as I had issues with handling URCs at the time.

[chinglee-iot]

Thank you for the feedback.
We will look into your suggestion.
If it is feasible to us, we will open another PR to update the implementation.

[tpecar-ltek]

Suggesting better names,

• pSavePtr could be pContent
• pTokenPtr could be pToken