Does BIO_read() behave differently on diff architectures?

Venkata Veldanda vvr.83 at yahoo.com
Fri Aug 9 09:19:37 UTC 2019


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))); 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190809/1b89f2ac/attachment-0001.html>


More information about the openssl-users mailing list