[17krishna8]

Description

The a_scale_radius field is a public astcenc_config tuning field, and the CLI also sets it directly from the -a <radius> option using atoi() with no bounds check (astcenccli_toplevel.cpp line 741). It can therefore hold any unsigned value, including 0xFFFFFFFF for a negative argument such as -a -1.

init_compute_averages() sizes the averaging pre-pass work memory as a product of padded block extents that grow linearly with the radius:

size_t max_padsize_xy = max_blk_size_xy + kerneldim;   // kerneldim = 2r + 1
size_t max_padsize_z  = max_blk_size_z + kerneldim;
ag.work_memory_size = 2 * max_padsize_xy * max_padsize_xy * max_padsize_z;

This size_t multiplication overflows for large radii, and even where it does not overflow the requested allocation grows without bound. compute_averages() performs the allocation with a bare new vfloat4[...] inside astcenc_compress_image(), so a large radius causes an uncaught std::bad_alloc, which terminates the process instead of returning an error code like every other invalid input to the codec:

$ astcenc -cl tiny.png out.astc 6x6 -fastest -a -1
terminate called after throwing an instance of 'std::bad_alloc'
Aborted

The same happens for moderate values such as -a 1000000, and the equivalent library-level config (a_scale_radius = 1000000) hits the same path.

Changes

• Clamp a_scale_radius in validate_config() to a new TUNE_MAX_A_SCALE_RADIUS constant (64), following the existing pattern used for the other tunable config fields. The work memory after the clamp is bounded to around 100 MB even for a 3D image, and practical alpha-scale use cases use single-digit radii (the test suite uses -a 1 and -a 2).
• Add a unit test compressing an image with a_scale_radius = 0xFFFFFFFF, which previously died with std::bad_alloc (or an ASAN allocation-size-too-big report) and now compresses normally.