Complex max_index const correctness

[jsallay]

I noticed that the 32fc_index_max/min kernels take in a non-const pointer:

static inline void volk_32fc_index_max_32u_a_avx2_variant_0(uint32_t* target,
                                                            lv_32fc_t* src0,
                                                            uint32_t num_points)

I think this is just an oversight. I should be able to submit a patch in the next few days.

[jdemel]

I assume you'd want to update to:

static inline void volk_32fc_index_max_32u_a_avx2_variant_0(uint32_t* target,
                                                            const lv_32fc_t* src0,
                                                            const uint32_t num_points)

I agree, this was probably an oversight. It could be related to very old API design as well. Answering this conclusively might require some code archeology.

The questions that come up:

• does this change API?
  • should not be a problem because adding const should have no effect.
• does this change ABI?
  • I'd like to clarify this.

[tomneda]

Same applies to

void volk_32fc_x2_square_dist_32f(float* target, lv_32fc_t* src0, lv_32fc_t* points,
unsigned int num_points)

and

void volk_32fc_x2_s32f_square_dist_scalar_mult_32f(float* target, lv_32fc_t* src0,
lv_32fc_t* points, float scalar, unsigned int num_points) 

where src0 and points should be const .

[jsallay]

From my cursory googling, it looks like the internet says that this is an ABI compatible change. Const is a compiler construct that doesn't exist in the actual executable. So (unlikely) optimizations may be in the new executable because it knows the array is const, but the interface should be identical.