It addresses the use of the libc str* functions but not the first point about the prototype of set_subject_alt_name. It's also discussed later in the thread: h

It addresses the use of the libc str* functions but not the first point about the prototype of set_subject_alt_name. It's also discussed later in the thread: http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100... > You note that there's really a small number of instances of strcat() in the code. That's true, but that's because you've provided your own _gnutls_str_cat() function instead, which is also heavily used. Assuming that strlen() isn't going to SEGV on you (which depends on dumb luck) this becomes just a question of efficiency. I also think that in the rebuttal the example is extremely poorly chosen since the code is equivalent to the much simpler char str[256] = "PKIX1.CRLDistributionPoints.?1.distributionPoint.fullName"; Assuming you even need str to be 256 char long, otherwise you would use 'char str[] = "...";' or 'const char *str = ' if you don't modify the string. Maybe the use of the concatenation is legitimate in the real code but I cannot judge that since it appears to have changed since the article was written: https://gitorious.org/gnutls/gnutls/source/d9ce82a4ce690857f828e6c434718c2a85bfbab0:lib/x509/extensions.c#L1041 https://gitorious.org/gnutls/gnutls/source/d9ce82a4ce690857f... No strcat in there. Maybe it wasn't such a good idea after all? :) EDIT: Actually, I dug into the git repo to find the old code and looked to revert to a commit around the date the blog post was written. Obviously I don't intend to get any work done this afternoon. I found this commit on the same day (2011/05/10): https://gitorious.org/gnutls/gnutls/commit/3df051196838f4f43f2350c637bb3fae3001ddaf https://gitorious.org/gnutls/gnutls/commit/3df051196838f4f43... "eliminated last instances of strcpy() and strcat() to keep pendantics happy." So the reason he says the problem is not here anymore is because he fixed it just before writing this blog post, more than 3 years after the openldap rant. I'm sure nmav was well-intentioned but it does weaken his rebuttal somewhat.