In src/ccid/CcidLocalAccess.c strings (uint8_t * or unsigned char , char ) of "unknown" length are used as function arguments. This can easily lead to reads exceeding array bounds if calling is not done carefully. A couple of places even use strcpy with that data. In the calling code this leads to awkward patterns like this:
A better idea would be to explicitly pass the (maximum) length of the string and use memcpy everywhere. (And why replicate the complex stuff instead of doing it inside the function?)
Furthermore consistent types should be used when passing around those pointers (uint8_t * seems like a good idea, since that is actually guaranteed to point to one byte). At the moment they are more or less randomly mixed and implicitly converted between three types in multiple places (even between signed and unsigned, which gcc issues warnings for).
A last concern. strcpy copies the terminating null character as well. Therefore, if the pattern above is used to ensure termination of a 25 char string which is copied into a 25 char array, the byte behind the array will also be set to 0. A similar situation occurs when comparing strings. I didn't check if there are precautions for this in place, but it illustrates how the approach taken here can lead to subtle errors and why it is often considered to be an antipattern.
In src/ccid/CcidLocalAccess.c strings (uint8_t * or unsigned char , char ) of "unknown" length are used as function arguments. This can easily lead to reads exceeding array bounds if calling is not done carefully. A couple of places even use strcpy with that data. In the calling code this leads to awkward patterns like this:
A better idea would be to explicitly pass the (maximum) length of the string and use memcpy everywhere. (And why replicate the complex stuff instead of doing it inside the function?)
Furthermore consistent types should be used when passing around those pointers (uint8_t * seems like a good idea, since that is actually guaranteed to point to one byte). At the moment they are more or less randomly mixed and implicitly converted between three types in multiple places (even between signed and unsigned, which gcc issues warnings for).
A last concern. strcpy copies the terminating null character as well. Therefore, if the pattern above is used to ensure termination of a 25 char string which is copied into a 25 char array, the byte behind the array will also be set to 0. A similar situation occurs when comparing strings. I didn't check if there are precautions for this in place, but it illustrates how the approach taken here can lead to subtle errors and why it is often considered to be an antipattern.