How about strscpy from the Linux kernel? https://www.kernel.org/doc/htmldocs/kernel-api/API-strscpy.html
28 сент. 2017 г. 4:23 ДП пользователь "Paul Eggert" <egg...@cs.ucla.edu> написал: > On 09/27/2017 05:35 PM, Bruno Haible wrote: > >> strlcpy with __warn_unused_result__ is the best solution for this task. >> > > No it's not, because strlcpy always computes the string length of the > source, and that is neither necessary nor desirable. Furthermore, in the > bad style of programming that uses strlcpy, it's often acceptable to ignore > the result since the programmer *wants* silent truncation. That is what > strlcpy means in OpenBSD etc., and we shouldn't be trying to reuse their > name for a function with different semantics. > > A better way to fix the test case is to remove its arbitrary limit on > month name lengths. That way, it won't need snprintf or strlcpy or strncpy > or anything like that. And it'll be following the GNU coding standards > better. I can propose a patch along those lines, if you like. I do not want > Gnulib to promote the use of strlcpy; that's a step in the wrong direction. > > If the same standards were set for test code >> than for application code, it would become even more tedious and >> boring to write unit tests than it already is. >> > In that case, snprintf suffices: maybe snprintf is not good enough for > production code, but it's plenty good for this test case. > > If you really want a function whose semantics are like strlcpy's but has > __warn_unused_result__ semantics (and while we're at it, also does not > count overlong sources, because that's silly), then I suppose we could > invent one and use it for Gnulib. But we should not call it strlcpy, and we > shouldn't use it in production code. > > >
