See attached patch.
>From f6c18450a99875647d85f633fef00e72a0c1577b Mon Sep 17 00:00:00 2001
From: sin
Date: Wed, 15 Apr 2015 09:43:06 +0100
Subject: [PATCH] Fix memmove() invocation with src/dst being NULL
This fixes a segmentation fault on some systems.
---
st.c | 7 +--
1 file changed, 5 i
> This should be reverted.
Yeah, I agree. I also think we should put some comment saying that
if i == 0 then it is possible to have some of the undefined cases
where src == NULL || dst == NULL || src == dst.
Some volunter to write the patch?
On Tue, Apr 14, 2015 at 04:39:44PM +0100, Dimitris Papastamos wrote:
> On Tue, Apr 14, 2015 at 04:33:56PM +0100, Connor Lane Smith wrote:
> > On 14 April 2015 at 13:50, Dimitris Papastamos wrote:
> > > dst and src are required to be valid objects even if n is 0, otherwise
> > > this is undefined b
On Tue, Apr 14, 2015 at 04:33:56PM +0100, Connor Lane Smith wrote:
> On 14 April 2015 at 13:50, Dimitris Papastamos wrote:
> > dst and src are required to be valid objects even if n is 0, otherwise
> > this is undefined behaviour.
>
> I looked this up in C11. Seems to be the case:
>
> > 7.24.2.1
On 14 April 2015 at 13:50, Dimitris Papastamos wrote:
> dst and src are required to be valid objects even if n is 0, otherwise
> this is undefined behaviour.
I looked this up in C11. Seems to be the case:
> 7.24.2.1.2. The memcpy function copies n characters from the object
> pointed to by s2 in
On Tue, Apr 14, 2015 at 01:43:56PM +0200, Silvan Jegen wrote:
> On Tue, Apr 14, 2015 at 12:55 PM, Gregor Best wrote:
> > The cause seems to be that for bot `term.line` and `term.alt` are NULL
> > at this point. While this does mean that even with a `len` parameter of
> > 0, the `dst` pointer gets
On Tue, Apr 14, 2015 at 12:55 PM, Gregor Best wrote:
> The cause seems to be that for bot `term.line` and `term.alt` are NULL
> at this point. While this does mean that even with a `len` parameter of
> 0, the `dst` pointer gets touched, I don't think it's ever right to call
> either `memcpy` or `m
This commit seems to cause st to segfault on start on OpenBSD
(-current). A similar segfault has been observed in #suckless by user
mvdan, using GNU libc.
The cause seems to be that for bot `term.line` and `term.alt` are NULL
at this point. While this does mean that even with a `len` parameter of
Applied, thanks.
> The assembly is rather irrelevant in this case. Let's write the code
> the way it is most understandable and clear.
Yeah, I totally agree with you here.
> I'd remove the if, memmove is equivalent to a non-op when the offset
> is 0.
But the problem now is to decide what is more understable. I
On Sun, 12 Apr 2015 11:36:00 +0200
koneu wrote:
> It is not a nop though, but two copy operations. Even with i=0 the
> function call might be more costly than a simple je.
The assembly is rather irrelevant in this case. Let's write the code
the way it is most understandable and clear.
I'd remove
On Sun, Apr 12, 2015 at 11:35:42AM +0200, Silvan Jegen wrote:
> I just wonder if it really will be copying the data around into a
> temporary array for no reason when i == 0 (either in glibc or in another
> libc).
Well, it does not really move data to temporary array, memmove just
chooses the righ
On April 12, 2015 10:56:40 AM CEST, non...@inventati.org wrote:
>On Sun, Apr 12, 2015 at 10:41:36AM +0200, Silvan Jegen wrote:
>> I was thinking about this option too but in that case you would be
>> calling memmove with an identical src and dst when i == 0. The man
>page
>> for glibc memmove(3) do
Heyhey
On Sun, Apr 12, 2015 at 08:56:40AM +, non...@inventati.org wrote:
> On Sun, Apr 12, 2015 at 10:41:36AM +0200, Silvan Jegen wrote:
> > I was thinking about this option too but in that case you would be
> > calling memmove with an identical src and dst when i == 0. The man page
> > for gl
On Sun, Apr 12, 2015 at 10:41:36AM +0200, Silvan Jegen wrote:
> I was thinking about this option too but in that case you would be
> calling memmove with an identical src and dst when i == 0. The man page
> for glibc memmove(3) does not mention anything about this being a noop
> so I am not sure th
On Sun, Apr 12, 2015 at 08:29:55AM +, noname wrote:
> ---
> st.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/st.c b/st.c
> index 109122e..f183803 100644
> --- a/st.c
> +++ b/st.c
> @@ -2788,10 +2788,8 @@ tresize(int col, int row) {
> free(term.
---
st.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/st.c b/st.c
index 109122e..f183803 100644
--- a/st.c
+++ b/st.c
@@ -2788,10 +2788,8 @@ tresize(int col, int row) {
free(term.line[i]);
free(term.alt[i]);
}
- if(i > 0) {
17 matches
Mail list logo
