Hi Wilson, On 23 November 2017 at 01:29, Wilson Lee <wilson....@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....@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 <s...@chromium.org> > > > Thanks, Simon. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
