An old arm memove.S patch's comment update was incompletely applied; result is confusing and wrong (tied to PR 36512)

[Mark Millard <markmi%dsl-only.net@localhost>]

[Going to http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd I
ended up unsure how to properly submit a bug for an incorrect/
misleading comment update that was made in an old patch.]

[For reference:
 http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=36512
]

The comment issue below was noticed in the activity of noticing
FreeBSD has the older style of code structure for the relevant
part of memmove.S. The issue has contributed to confusions for
the FreeBSD activity. FreeBSD still has the older type of arm
code structure involved and a couple of folks have been trying
to get the same type of code-correction in place.

The original change listed in netbsd's PR 36512 listed (note the
comment's "an" vs. "old"):

-	cmp	r3, r2		/* if (r3 < len) we have an overlap */
vs.
+	cmp	r3, r2		/* if (r3 >= len) we have no overlap */

Looking at it I agree with the comment update being accurate
to the updated code. But the actual source shown in the likes of:

http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/arch/arm/string/memmove.S.diff?r1=1.1&r2=1.2

(with r2=1.2 or later) shows:

+	cmp	r3, r2		/* if (r3 >= len) we have an overlap */

(still "an"). So the official comment is misleading by being
incorrect from what I understand.

This involves both:

src/lib/libc/arch/arm/string/memmove.S
and:
sys/lib/libkern/arch/arm/memmove.S

So both kern and lib, at least as PR 36512 lists
things.

In FreeBSD's Bugzilla the report and notes involved
are in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217065


Note, I'd be happy to submit via:

http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd

if I'm told what is appropriate for:

Category (kern? lib?)
Class (sw-bug? doc-bug?
       Are comments classified as internal-documentation?)
"The NetBSD release where you encountered the problem"
      ("N/A" okay here?)

"Environment" (uname -a) does not really apply. Nor does
"How to repeat the problem": at least for my part of this
no execution of netbsd was involved. So for these I'd
expect "N/A".


===
Mark Millard
markmi at dsl-only.net