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
On Thu, Sep 28, 2017 at 12:25 AM, Eric Blake wrote:
> [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 un
On Thu, Sep 28, 2017 at 2:05 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Thu, Sep 28, 2017 at 12:25 AM, Eric Blake wrote:
>
>> [adding gnulib]
>>
>
> [...]
>
>>
> then libvirt needs to pick up the
>> updated gnulib.
>
>
> I copied in current gnulib from git and it
The gettext (0.19.8.1-4) package contains pretty old m4 files.
With 'autoreconf -fi' all that old stuff is copied into m4/ though there
are newer versions from gnulib in gl/m4 and lib/gl/m4/.
Removing m4/ and later on using autoreconf without -fi does the job
(resp. doesn't copy unwanted stuff in
Tim Rühsen wrote:
> The gettext (0.19.8.1-4) package contains pretty old m4 files.
>
> With 'autoreconf -fi' all that old stuff is copied into m4/ though there
> are newer versions from gnulib in gl/m4 and lib/gl/m4/.
>
> Removing m4/ and later on using autoreconf without -fi does the job
> (resp
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/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
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.
Paul Eggert wrote:
> If you really want a function whose semantics are like strlcpy's but has
> __warn_unused_result__ semantics ..., then I suppose we could
> invent one and use it for Gnulib. But we should not call it strlcpy
Yes, I do want such a function for copying a string to a bounded mem
>> Though I would change its ssize_t
>> to ptrdiff_t, so that it depends only on stddef.h.
> - The mixed use of ssize_t vs. size_t.
What's wrong with ssize_t? As for me, ptrdiff_t is not a good choice here,
because it represents not length, but difference between pointers. String
length IS a d
On 09/28/2017 11:39 AM, Bruno Haible wrote:
in BSD, it is common practice to try
a call with a fixed-size stack-allocated or statically allocated buffer,
and try dynamic memory only when this first attempt fails.
This doesn't match my experience with BSD application code, where the
most common
On 09/28/2017 12:36 PM, Dmitry Selyutin wrote:
ptrdiff_t is not a good choice here, > because it represents not length, but
difference between pointers
They're the same concept in C. In 7th Edition Unix strlen returned int,
and this was better than having it return an unsigned type due to comm
That patch essentially negates the point of the test, which is that
getopt should be visible from unistd.h. I'd rather fix the problem than
nuke the test.
Could you explain what the Gnulib problem is here? I can't really see it
in your email. A self-contained example would help.
For what it'
13 matches
Mail list logo
