Adrian Colyer presents a whitepaper by Wressnegger et al. on bugs caused by 32 to 64 bit transition. The paper deals specifically with going from the ILP32 data model used by Win32 and Linux, to the LLP64 (Win64) and LP64 (Linux) data models.
They did also find genuine vulnerabilities among those issues, in every single area the theory predicted they might exist. These include vulnerabilities in high profile projects such as Google's Chromium, the GNU C Library, the Linux Kernel, and the Boost C++ Libraries. The paper contains case studies in each of these areas.
Lots of people have studied integer-based flaws, but this is the first work to consider those introduced solely from the migration to 64-bit. Another thing to add to the ever-growing worry list!
I think if somebody is being careless this might sound unintuitive. Also it's always nice to see real life results that corroborate theory.
(Score: 2) by Shimitar on Monday November 21 2016, @07:55AM
We ported quite a bit of legacy 32bit software, written not by software engineers or coders but by matematicians or phisics graduates. Well, i was worried, but overall zero issues. Really, i call this a non-issue. Of course, we had to spot the rare occasion where pointers where stored into ints (and we even run into somebody who used two arrays of "unsigned int" to hold the same pointers to a set of data which was either floats or integers depending on a second array...)
... but besides the fun we had in revieweing tons of "funny" code, again, no issues. The source platform was Linux32 and the target Linux64.
The compiler had, anyway, found out 99.99% of the issues in compilation and a bit of static analysis fixed all the rest. Still it took months for everybody to trust the recompiled code, i guess it's fear for the change.
Anyway, it was a "huge" codebase, but i understand "huge" is not a reference. I don't have SLOCS, sorry!
Coding is an art. No, java is not coding. Yes, i am biased, i know, sorry if this bothers you.