Isn't there a preparatory step to foresee so that (int)src.total() can be src.total() instead, in case of an hal implementation ? (I think there is none for now)

if (src.isContinuous() && mask.isContinuous())
    {
        CALL_HAL(meanStdDev, cv_hal_meanStdDev, src.data, 0, (int)src.total(), 1, src.type(),
                 _mean.needed() ? mean_mat.ptr<double>() : nullptr,
                 _sdv.needed() ? stddev_mat.ptr<double>() : nullptr,
                 mask.data, 0);
    }

Isn't there a preparatory step to foresee so that (int)src.total() can be src.total() instead, in case of an hal implementation ? (I think there is none for now)

if (src.isContinuous() && mask.isContinuous())
    {
        CALL_HAL(meanStdDev, cv_hal_meanStdDev, src.data, 0, (int)src.total(), 1, src.type(),
                 _mean.needed() ? mean_mat.ptr<double>() : nullptr,
                 _sdv.needed() ? stddev_mat.ptr<double>() : nullptr,
                 mask.data, 0);
    }

Your concern is valid, can do the following

if (src.isContinuous() && mask.isContinuous())
{
    const size_t tpix = src.total();
    CALL_HAL(meanStdDev, cv_hal_meanStdDev, src.data, 0, tpix, 1, src.type(),
             _mean.needed() ? mean_mat.ptr<double>() : nullptr,
             _sdv.needed() ? stddev_mat.ptr<double>() : nullptr,
             mask.data, 0);
}

The prototype of cv_hal_meanStdDev is currently cv_hal_meanStdDev(..., int width, int height, ...), so just using a size_t tpix for width and 1 for height won't solve anything.
Either the prototype of cv_hal_meanStdDev() must change to accept size_t arguments, or it can only be used if width*height does not overflow.

@shyama7004, the added test requires 16Gb of RAM. That's a huge number, quite inconvenient for our CI. I suggest to, first of all, consider 8U type for array, not 32F and then reduce size of the array to a smaller number of elements, ~2 billions or so (e.g. (1<<16) x ((1<<15) + 10)). It will still cause 32-bit integer overflow, but it will take 8x less space than the current version

@shyama7004, the added test requires 16Gb of RAM. That's a huge number, quite inconvenient for our CI. I suggest to, first of all, consider 8U type for array, not 32F and then reduce size of the array to a smaller number of elements, ~2 billions or so (e.g. (1<<16) x ((1<<15) + 10)). It will still cause 32-bit integer overflow, but it will take 8x less space than the current version

Ok I will implement this