TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

strcpy: A niche function you don't need

150 点作者 grep_it将近 4 年前

16 条评论

TazeTSchnitzel将近 4 年前
My favourite C string function is snprintf:<p>• It takes a buffer size and truncates the output to the buffer size if it&#x27;s too large.<p>• The buffer size includes the null terminator, so the simplest pattern of snprintf(buf, sizeof(buf), …) is correct.<p>• It always null-terminates the output for you, even if truncated.<p>• By providing NULL as the buffer argument, it will tell you the buffer size you need if you want to dynamically allocate.<p>And of course, it can safely copy strings:<p><pre><code> snprintf(dst_buf, sizeof(dst_buf), &quot;%s&quot;, src_str); </code></pre> Including non-null-terminated ones:<p><pre><code> snprintf(dst_buf, sizeof(dst_buf), &quot;%.*s&quot;, (int)src_str_len, src_str_data); </code></pre> And it&#x27;s standard and portable, unlike e.g. strlcpy. It&#x27;s one of the best C99 additions.
评论 #28013649 未加载
评论 #28014121 未加载
评论 #28013329 未加载
评论 #28017753 未加载
评论 #28012844 未加载
jonathrg将近 4 年前
It&#x27;s too bad that many of the string handling functions in the C standard library are ticking time bombs. I like the approach taken in e.g. git which converts problematic function calls into compile errors <a href="https:&#x2F;&#x2F;github.com&#x2F;git&#x2F;git&#x2F;blob&#x2F;master&#x2F;banned.h" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;git&#x2F;git&#x2F;blob&#x2F;master&#x2F;banned.h</a>
评论 #28016039 未加载
评论 #28012448 未加载
评论 #28012670 未加载
barosl将近 4 年前
When I used C for a serious project, I always used `snprintf(dst, sizeof(dst), &quot;%s&quot;, src);` to copy a string. It might be a little bit slow, but it freed me from all the headaches of identifying different string functions of C and remembering their subtle differences. It also is useful for other purposes, e.g. prefixing a string.
评论 #28012516 未加载
评论 #28014132 未加载
jabl将近 4 年前
C2X will be adding memccpy() (note two c&#x27;s in the middle, not memcpy!). Overview and justification at <a href="https:&#x2F;&#x2F;developers.redhat.com&#x2F;blog&#x2F;2019&#x2F;08&#x2F;12&#x2F;efficient-string-copying-and-concatenation-in-c" rel="nofollow">https:&#x2F;&#x2F;developers.redhat.com&#x2F;blog&#x2F;2019&#x2F;08&#x2F;12&#x2F;efficient-stri...</a>
评论 #28012607 未加载
评论 #28015604 未加载
corndoge将近 4 年前
Not sure I agree with the recommendation against strlcpy. While it is technically true that if you can&#x27;t replace strcpy with memcpy you&#x27;re using strcpy wrong, it&#x27;s also true that most uses of strcpy are wrong, which I think is a better point to make. The stated purpose of strcpy is to copy a string, and if you&#x27;re copying a string your best bet is strlcpy. The article is worded in such a way that you&#x27;d walk away thinking &quot;I should always use memcpy.&quot;
评论 #28012363 未加载
legulere将近 4 年前
Even better is to not null terminate strings and use pointer plus length everywhere.
评论 #28012641 未加载
评论 #28012491 未加载
评论 #28012508 未加载
评论 #28014451 未加载
评论 #28012732 未加载
评论 #28014601 未加载
andrewmcwatters将近 4 年前
What&#x27;s the standard practice these days in C to move strings with lengths around? I&#x27;ve been out of C for at least a couple of years now, but I can&#x27;t imagine it&#x27;s changed in that time.
评论 #28012686 未加载
评论 #28012534 未加载
csnover将近 4 年前
Related: Designing a Better strcpy, from last month[0]<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27537900" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27537900</a>
howtofly将近 4 年前
I found the article kind of misleading: using memcpy for c-string is generally a bad idea, unless string length is bound with string buffer like std::string. Otherwise it will make code review very difficult.<p>In our team c-string is prefixed with sz_, e.g. char sz_name[13], and we always use a safe subset(or a safe replacement) of strxxx functions with these sz_ prefixed variables. Using memxxx with sz_ variables is explicitly forbidden, since it may break the NULL-terminating contract.<p>The sz_ prefix convention is by no ways like the hungarian naming nonsense. Suppose that you have &quot;char sz_name[13]&quot; in a structure of configuration parameters, sz_ tells the guy changing the field to keep it NULL-terminated, if they don&#x27;t, it&#x27;s their fault. On the other side, users of this field can safely use printf(&quot;%s&quot;, sz_name) without the risk of crashing the program.<p>For safe replacements of strcpy, I recommend: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27537900" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27537900</a>
aidenn0将近 4 年前
MSVC is a very curious choice of strcpy_s implementation given that MSVC is openly not compliant with C11, much less Annex K.<p>OpenWatcom, which implements a late draft of the standard behaves as expected on their testcase:<p><pre><code> Runtime-constraint violation: strcpy_s, s1max &gt; RSIZE_MAX. ABNORMAL TERMINATION </code></pre> The reason not to use the _s versions isn&#x27;t that they are bad, it&#x27;s that basically nobody has implemented them (hence me having to use Open Watcom to demonstrate this example)<p>[edit]<p>Just noticed that in the page they linked to at the top when they mention strcpy_s, it notes that the MSVC implementation predates even the original draft of the standard and lacks RSIZE_MAX.
评论 #28016191 未加载
b33j0r将近 4 年前
If this is the case, why aren’t the stdlib functions defined this way? In all of the history of the longest-lived production language family besides FORTRAN, this blog post is the first voice to point out that memcpy should be the same operation as strcpy for null-terminated strings? What is going on here?<p>(Rust crowd snickers as they unwrap&lt;‘jk&gt; &amp;mut *foo_buf)
评论 #28014137 未加载
评论 #28012571 未加载
ncmncm将近 4 年前
Know what&#x27;s even worse than strcpy?<p>strlcpy.<p>Every use of it I have seen was subtly incorrect. To use it correctly takes more code than anybody wants to write, or (AFAICT) ever does.<p>strcat is worse than both, though.
matheusmoreira将近 4 年前
Not just strcpy either. Pretty much all str* functions are bad and should be replaced with their mem* equivalents when available.<p>I don&#x27;t even know why the str* functions exist. They&#x27;re just worse versions of mem* functions.
评论 #28017050 未加载
Animats将近 4 年前
Should have been deprecated around 1990 and removed by 2005.
einpoklum将近 4 年前
One-liner summary: Author suggests using just memcpy() typically, strncpy() rarely&#x2F;maybe, and even more rarely, or never, strcpy().
评论 #28012364 未加载
评论 #28012349 未加载
forrestthewoods将近 4 年前
God the C runtime library is so bad. So is the C++ STL.<p>I think it’s a travesty that these languages defined an API but didn’t provide an implementation. Hindsight is 20&#x2F;20, but what a nightmare!<p>It is far more rational to provide an implementation using standard language features. It’s not like strcpy needs to make a syscall!
评论 #28016602 未加载