How about strscpy from the Linux kernel?
https://www.kernel.org/doc/htmldocs/kernel-api/API-strscpy.html
28 сент. 2017 г. 4:23 ДП пользователь "Paul Eggert"
написал:
> On 09/27/2017 05:35 PM, Bruno Haible wrote:
>
>> strlcpy with __warn_unused_result__ is the best solution for this task.
>>
>
>
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
On Wed, Sep 27, 2017 at 5:44 PM, Bruno Haible wrote:
> I wrote:
>>In some places the users
>>will notice that strlcpy does not buy them much, compared to the
>>"avoid arbitrary limits"[1] approach, and will switch over to what
>>you call "GNU style". In other places, they will inse
I wrote:
>In some places the users
>will notice that strlcpy does not buy them much, compared to the
>"avoid arbitrary limits"[1] approach, and will switch over to what
>you call "GNU style". In other places, they will insert an abort()
>or assert() to handle the truncation case
Hi Paul,
> Anyway, strlcpy is overkill here, as snprintf does the job just as well
> here
Not at all. snprintf is not at the right level of abstraction.
There are three levels of abstractions to consider:
(1) C code which composes a memory region by writing to bytes individually.
(2) C cod
I'd really rather not promote the use of strlcpy in GNU code, as it is
contrary to GNU style. Plus, I'm not a fan of __warn_unused_result__; in
my experience it's too often more trouble than it's worth, and I expect
this trouble would occur with strlcpy if we started using it.
That being said,
Paul Eggert wrote:
> @@ -48,7 +48,8 @@ get_locale_dependent_values (struct locale_dependent_values
> *result)
>snprintf (result->numeric, sizeof (result->numeric),
> "%g", 3.5);
>/* result->numeric is usually "3,5" */
> - strcpy (result->time, nl_langinfo (MON_1));
> + strnc
[adding gnulib]
On 09/27/2017 04:36 PM, Christian Ehrhardt wrote:
> Hi,
> there seems to be an incompatibility to the last glibc due to [1].
Gnulib needs to be updated to track the glibc changes (it looks like
that is actually under way already), then libvirt needs to pick up the
updated gnulib.
I can confirm that make works properly with the compat glob symbol.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
