[U-Boot] [PATCH] lib: sha1: Change uint8_t to unsigned char for sha1_der_prefix array.

[Simon Glass]

Hi Wilson,

On 23 November 2017 at 01:29, Wilson Lee <wilson.lee at ni.com> wrote:
> Hi Simon,
>
> On Mon, 2017-11-20 at 08:38 -0700, Simon Glass wrote:
>> Hi Wilson,
>>
>> On 7 November 2017 at 19:30, Wilson Lee <wilson.lee at ni.com> wrote:
>> >
>> > uint8_t used in sha1_der_prefix array was not able to recognize by
>> > compiler when try to build the tools using 'HOSTCC'. That is
>> > because,
>> > uint8_t is undefined when 'HOSTCC' is defined because asm/type.h is
>> > not
>> > included in that case. Use unsigned char for sha1_der_prefix[]
>> > array
>> > instead.
>> >
>> > This commit is to remove and change the uint8_t to unsigned char
>> > for
>> > sha1_der_perfix[] array.
>> nit: prefix
>>
>> This change is OK I suppose. But I'm not sure what compiler you are
>> using. This type should be provided in stdint.h - can you take a look
>> at why it is not?
>>
>> Regards,
>> Simon
>
> Kindly correct me if I am wrong. I think the uint8_t was provided in
> the "inttypes.h" header file. However, when we using HOSTCC to compile
> the code, the "common.h" (which include "inttypes.h") does not included
> and cause compilation to fail. The summary version of the code shown
> below:
>
> #ifndef USE_HOSTCC
> #include <common.h>
> #include <linux/string.h>
> #else
> #include <string.h>
> #endif /* USE_HOSTCC */
>
>
> I think there have 2 solution for this:
>     1. Include the "inttypes.h" header file.
>     2. Change the uint8_t to unsigned char.
>
> However, I would like to proceed with 2nd option. Because, in existing
> sha1 library, variable data type was declare as unsigned char, unsigned
> long... and I am thinking convert uint8_t to unsigned char will make
> the variable data type more consistent in sha1 library code.

OK I see. Yes that seems best considering only sha1, but I see that
sha256 uses uint8_t pretty consistently. I see that hash_block() uses
uint8_t also. But crc.h uses unsigned char.

Can you try option 1 and see if it works? I feel it is better to use
uint8_t and you would have this same problems with sha256.

But if you want to stick with this patch, it is a a small local change
that does not affect the API, so:

Reviewed-by: Simon Glass <sjg at chromium.org>

>
>
> Thanks, Simon.

Regards,
Simon