Yes, because "unsigned long" on _LP64 is not 32bits. What is the undefined behavior you are trying to fix?
christos > On Feb 15, 2020, at 7:03 PM, nisarg joshi <njnis...@gmail.com> wrote: > > Hi community, > > > > While trying to fix UBSan Undefined behavior reports for md4_dgst.c and > rmd_dgst.c files which reported issues for the overflow of signed ints etc, I > came across a possible out of sync tree of openssl crypto implementations. > > > > The UBSan report required usage of unsigned int(or long) for MD32_REG_T type > and upon checking the upstream openssl/openssl, it seemed to be using the > correct data type that would not throw that particular error. Upon tracing > the changes in NetBSD openssl code, I found that there was a commit that made > changes to the openssl version imported from upstream in 2009. The commits > are: > > 1.) Original codebase ==> > https://github.com/NetBSD/src/commit/df8082221a1522cb9f9711f39f81796132552e1d > <https://github.com/NetBSD/src/commit/df8082221a1522cb9f9711f39f81796132552e1d> > 2.) Changes made ==> > https://github.com/NetBSD/src/commit/309c6b7ae7a7de3f477f9f707d08a4fc12f01b62 > <https://github.com/NetBSD/src/commit/309c6b7ae7a7de3f477f9f707d08a4fc12f01b62> > > The 2nd commit listed above made changes to the original codebase in such a > way that it changed MD32_REG_T to uint32_t and diverged from the upstream. > But later MD32_REG_T has been changed to int or long and has become out of > sync with the upstream implementation. These changes not only affect the > files mentioned earlier but also affect a lot of the files. > > > > I would request someone to look into the matter and try to sync the > implementation and our local modifications to the upstream. > > > > Thank You > > Nisarg S. Joshi > > > <sanitizer.log>
signature.asc
Description: Message signed with OpenPGP