Within the low level standard C programming commmunity the terms Byte and Char are interchangable and vary by architecture or domain (8 bits in a networking application domain, potentially more bits on various target architectures).
https://registry.khronos.org/OpenCL/specs/2.2/html/OpenCL_C....
> OpenCL (Open Computing Language) is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs) and other processors or hardware accelerators.
Here's the thing, any processing done on 32 bit | 64 bit RISC like DSP chips can talk about having an 8 bit char .. but these will be embedded within a 64 bit "smallest addressable unit" as the hardware pointers iterate from one 64 bit (or 32 bit) chunk to the next.
There are also (within the DSP components) restrictions on masking out 8 bit segments of a 64 bit "smallest addressable chunk" as the hardware is optimised for integer and float operations w/out a care for delicate little 8 bit operations.
In other words, in a hybrid Franken-beast creating "images" from convolutions and signal operations, the hardware that writes packed image formats with OpenCL char types will not (can not) be DSP type hardware that convolves and fouriers the computations that create the "now package me" pre-final image sets.
Returning to the base point, the mere fact that sometime a char is 8 bits ion no way requires a char to always be 8 bits .. if you read about it is most generally defined as "at least 8 bits".