Re: [hackers] [st][PATCH] rm unnecessary explicit zeroing

From: Roberto E. Vargas Caballero <k0ga_AT_shike2.com>
Date: Thu, 17 Mar 2022 21:44:35 +0100

Hi,

On Thu, Mar 17, 2022 at 08:36:15PM +0100, Laslo Hunhold wrote:
>
> > On Tue, Mar 15, 2022 at 04:30:52PM +0600, NRK wrote:
> > > +static const char base64_digits[(unsigned char)-1] = {
> >
> > Any reason to write "(unsigned char)-1" instead of writing 256?
>


Thank you for your aclaration, but sadly I think you didn't understand
the code and you didn't understand my comment. ISO/IEC 9899:1999
Section 6.7.8 paragrah 6:

        If a designator has the form

                  [ constant-expression ]

        then the current object (defined below) shall have array type and
        the expression shall be an integer constant expression. If the array
        is of unknown size, any nonnegative value is valid.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

        {CHAR_BIT}
                Number of bits in a type char.
                [CX] Value: 8

POSIX mandates CHAR_BIT to be 8. The type of an array size is always
int. So againg, what is the point of "(unsigned char)-1"?


> char is not guaranteed to be 8-Bit (unless we assume Posix, which is

The full code of st assumes POSIX, do I have to explain this to you after
so many years?

> reasonable within Posix), and you probably meant 255. An alternative
> would be to go with UCHAR_MAX from limits.h.

I meant 256. If you want to be able to use any unsigned char as index
in the array then you need 256 positions, from 0 to 255. The patch
also had that wrong.

Also, the comment of the patch only stayed that it was avoiding zeroing,
it didn't say anything about trying (but failing) increase the portability
of the code. It was a unneded modification for the target of the patch
(as it was described in the comment of the commit).

Regards,
Received on Thu Mar 17 2022 - 21:44:35 CET

This archive was generated by hypermail 2.3.0 : Thu Mar 17 2022 - 21:48:37 CET