StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>When people say, "<code>strcpy()</code> is dangerous, use <code>strncpy()</code> instead" (or similar statements about <code>strcat()</code> etc., but I am going to use <code>strcpy()</code> here as my focus), they mean that there is no bounds checking in <code>strcpy()</code>. Thus, an overly long string will result in buffer overruns. They are correct. Using <code>strncpy()</code> in this case will prevent buffer overruns. </p> <p>I feel that <code>strncpy()</code> really doesn't fix bugs: it solves a problem that can be easily avoided by a good programmer.</p> <p>As a C programmer, you <em>must</em> know the destination size before you are trying to copy strings. That is the assumption in <code>strncpy()</code> and <code>strlcpy()</code>'s last parameters too: you supply that size to them. You can also know the source size before you copy strings. Then, if the destination is not big enough, <em>don't call <code>strcpy()</code></em>. Either reallocate the buffer, or do something else.</p> <p>Why do I not like <code>strncpy()</code>?</p> <ul> <li><code>strncpy()</code> is a bad solution in most cases: your string is going to be truncated without any notice—I would rather write extra code to figure this out myself and then take the course of action that I want to take, rather than let some function decide for me about what to do.</li> <li><code>strncpy()</code> is very inefficient. It writes to every byte in the destination buffer. You don't need those thousands of <code>'\0'</code> at the end of your destination.</li> <li>It doesn't write a terminating <code>'\0'</code> if the destination is not big enough. So, you must do so yourself anyway. The complexity of doing this is not worth the trouble.</li> </ul> <p>Now, we come to <code>strlcpy()</code>. The changes from <code>strncpy()</code> make it better, but I am not sure if the specific behavior of <code>strl*</code> warrants their existence: they are far too specific. You still have to know the destination size. It is more efficient than <code>strncpy()</code> because it doesn't necessarily write to every byte in the destination. But it solves a problem that can be solved by doing: <code>*((char *)mempcpy(dst, src, n)) = 0;</code>.</p> <p>I don't think anyone says that <code>strlcpy()</code> or <code>strlcat()</code> can lead to security issues, what they (and I) are saying that they can result in bugs, for example, when you expect the complete string to be written instead of a part of it.</p> <p>The main issue here is: how many bytes to copy? The programmer must know this and if he doesn't, <code>strncpy()</code> or <code>strlcpy()</code> won't save him.</p> <p><code>strlcpy()</code> and <code>strlcat()</code> are not standard, neither ISO C nor POSIX. So, their use in portable programs is impossible. In fact, <code>strlcat()</code> has two different variants: <a href="https://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/library-c.html" rel="noreferrer">the Solaris implementation is different from the others</a> for edge cases involving length 0. This makes it even less useful than otherwise.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload