https://bugs.kde.org/show_bug.cgi?id=454482
--- Comment #3 from Alfred Polanco <alfred.pola...@broadcom.com> --- Thank you for your response. The honest answer to your question is that this code was ported forward to 64-bit from an earlier 32-bit implementation. I acknowledge that this implementation can run into issues in the near future and I will raise a support ticket on my end to look into replacing this implementation. In the meantime, however, the implementation compiles and executes as expected for now. In addition, while the information of the link below agrees with you (and now, so do I) that this is a poor 64-bit implementation and alternatives exist, it does allude to a possible use-case for this implementation: https://stackoverflow.com/questions/46087730/what-happens-if-you-use-the-32-bit-int-0x80-linux-abi-in-64-bit-code However, in the majority of use cases, the main reason you can expect to see the use of 0x80 will be due to code that was lazily ported over to 64-bits from 32-bits, as is our case. In our case, the intent of the code is to execute a call to getuid internally to prevent the function from being externally hijacked in an hacking attempt to impersonate a user. The 32-bit version of valgrind has no obvious issues executing this code so it came as a bit of a shock that the 64-bit version of valgrind immediately generated a core file. It is conceivable that others may run into a similar situation after porting similar code over. -- You are receiving this mail because: You are watching all bug changes.
