Paul Eggert wrote:
> > Here's doc I propose to add to the gnulib documentation (and similar one
> > to wcscpy and wcsncpy):
>
> Thanks, that looks good. I too share an aversion to strncpy
ok, I'm committing this doc change:
2017-10-03 Bruno Haible
doc: warn about misuse of strncpy a
On 09/28/2017 10:54 AM, Bruno Haible wrote:
Here's doc I propose to add to the gnulib documentation (and similar one
to wcscpy and wcsncpy):
Thanks, that looks good. I too share an aversion to strncpy, and wish
that I had not stirred up this hornet's nest by using it in a moment of
weakness.
On 09/27/2017 11:29 PM, Dmitry Selyutin wrote:
How about strscpy from the Linux kernel?
Yes, that's a better API than strlcpy. Though I would change its ssize_t
to ptrdiff_t, so that it depends only on stddef.h. Plus, I would define
its behavior even if the buffers overlap - that's safer, and
Hi Jim,
> I developed a strong aversion to strncpy, and wrote this about it:
> https://meyering.net/crusade-to-eliminate-strncpy/
Thanks for your voice and past effort here.
Here's doc I propose to add to the gnulib documentation (and similar one
to wcscpy and wcsncpy):
diff --git a/doc/posix-f
On 09/28/2017 08:29 AM, Dmitry Selyutin wrote:
> How about strscpy from the Linux kernel?
>
> https://www.kernel.org/doc/htmldocs/kernel-api/API-strscpy.html
As an application library & programmer, I need this (thanks, Dmitry)
*and* strlcpy. A gnulib module would reduce configure.ac code and
seve
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,
ncation can occur.
To prevent this, the proposed patch declares strlcpy with
__attribute__((__warn_unused_result__)) on all platforms.
Bruno
>From dc4a8d880cb3be138b96b682ae57a10259a67ba4 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Thu, 28 Sep 2017 00:30:05 +0200
Subject: [PATCH 1/
12 matches
Mail list logo
