On Mon, 06 Dec 2021 19:29:55 -0600, Scott Cheloha wrote:
> This?
I think this is fine. OK millert@
- todd
Scott Cheloha wrote:
> On Mon, Dec 06, 2021 at 03:09:05PM -0700, Theo de Raadt wrote:
> > +* Use memmove(3) instead of memcpy(3), just in case key
> > +* partially overlaps with the end of the array.
> >
> > It isn't a "just in case", as in a possibility.
>
> ?
>
> > It is gaur
On Mon, Dec 06, 2021 at 03:09:05PM -0700, Theo de Raadt wrote:
> +* Use memmove(3) instead of memcpy(3), just in case key
> +* partially overlaps with the end of the array.
>
> It isn't a "just in case", as in a possibility.
?
> It is gauranteed this condition will happen.
I don
+* Use memmove(3) instead of memcpy(3), just in case key
+* partially overlaps with the end of the array.
It isn't a "just in case", as in a possibility.
It is gauranteed this condition will happen.
I don't like how these conditions are described as odd-cases, that
isn't how mach
On Mon, Dec 06, 2021 at 01:47:52PM -0700, Todd C. Miller wrote:
> On Mon, 06 Dec 2021 09:03:43 -0600, Scott Cheloha wrote:
>
> > In lsearch(3), the key is allowed to overlap with the last element in
> > base. We need to memmove(3), not memcpy(3), or we could corrupt the
> > key in that edge case.
On Mon, 06 Dec 2021 09:03:43 -0600, Scott Cheloha wrote:
> In lsearch(3), the key is allowed to overlap with the last element in
> base. We need to memmove(3), not memcpy(3), or we could corrupt the
> key in that edge case.
OK, but does this deserve a comment so to that effect to prevent
someone
In lsearch(3), the key is allowed to overlap with the last element in
base. We need to memmove(3), not memcpy(3), or we could corrupt the
key in that edge case.
ok?
Index: lsearch.c
===
RCS file: /cvs/src/lib/libc/stdlib/lsearch.c,v
