Open yuvpg opened 1 year ago
In the documentation I can read:
The
pDst
should be initialized to all zeros before being used.
and also in documentation:
size of buffer should 2 * max(srcALen, srcBLen) - 1
So I don't see any bug. It behaves as expected but I agree that it may be improved to use less memory.
I think the reason it is done like that is to:
From the documentation :
The result
c[n]
is of length2 * max(srcALen, srcBLen) - 1
and is defined over the intervaln=0, 1, 2, ..., (2 * max(srcALen, srcBLen) - 2)
. The output result is written topDst
and the calling function must allocate2 * max(srcALen, srcBLen) - 1
words for the result.
but should not the result c[n]
be defined over the interval n=0, 1, 2, ..., srcALen + srcBLen - 2
? Since a full correlation returns an array of size srcALen + srcBLen - 1
.
Edit
Depending of whether scrALen
is greater than srcBLen
(or not), c[n]
is not defined on the same interval.
If srcALen < srcBLen
then n=0, 1, 2, ..., srcALen + srcBLen - 2
.
If srcALen > srcBLen
then n=srcALen-srcBLen,..., 2*srcALen - 2
I found the documentation a bit misleading about the definition domain of c
.
@rohardy The output is padded with zeros. It is longer than what is strictly needed.
@christophe0606 I understand, but I think the documentation could be more precise about where the actual result lays.
@rohardy You're right. Documentation will be improved.
arm_correlate_f32()
expecting the output array size to be2*srcALen - 1
instead ofsrcALen + srcBLen - 1
forARM_MATH_DSP
case.Maybe just changing line 361 will be enough to fix the issue.
Now the output is unexpected, and call leads to buffer overflow if you don't guess output array size correctly:
results in