@Andrew - Thanks for pointing that out. Indeed, that was the issue.
Get Outlook for Android On Fri, Aug 9, 2019 at 6:18 PM +0530, "Lynch, Andrew" <andrew.ly...@atos.net> wrote: Hi, Your issue is not with BIO_read(), but with the differing signedness of the char type on your two platforms. On your PPC platform the char type defaults to unsigned, on your x86 platform it is signed. The %x format expects an unsigned int, so on x86 the signed char values are being sign-extended to int which adds the ffffff to any values where the high bit is set (i.e. seen as negative). One possible fix: Change "char *ptr = buf;" to "unsigned char *ptr = buf;", then you should get the expected output. Regards, Andrew. From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Venkata Veldanda via openssl-users Sent: Friday, August 09, 2019 11:20 AM To: openssl-users@openssl.org Subject: Does BIO_read() behave differently on diff architectures? Hi Experts, I am using openssl 1.0.2 I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read(). I read a 20bytes of data using BIO_read like following.. int res = BIO_read(bio, buf, 20); char *ptr = buf; The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures. For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result. 22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30 This is what I was getting on my PPC platform which is as expected with the same app code. 22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30 Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so. I print the above output using the following code. INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x," "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x", ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4), *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9), *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14), *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19)));
