Source Activity

* Incorrect handling of realloc() failure (if reallocation fails, original buffer is still allocated and must be freed), * Use of bit shift on signed integer (undefined behavior in C and C++). * Incorrect handling of realloc() failure (if reallocation fails, original buffer is still allocated and must be freed), * Use of bit shift on signed integer (undefined behavior in C and C++).

Thanks to luroh for noticing. Thanks to luroh for noticing.

Calling Debugger here causes issues with some software (mainly Mesa). Only print a warning, this is enough for developers to see the problem, and not as annoying for users. Calling Debugger here causes issues with some software (mainly Mesa). Only print a warning, this is enough for developers to see the problem, and not as annoying for users.

Fixes #12006. Signed-off-by: Adrien Destugues Fixes #12006. Signed-off-by: Adrien Destugues

Fixes #12028. Fixes #12028.

And copyright notices, of course. And copyright notices, of course.

The Be Book [1] states that these are supposed to be C functions, but the comment (see diff) said they were deprecated, and the fact that they were in a .cpp file (and I checked with "nm") made them C++ functions. I can't recall any applications failing to start because these symbols were unresolved, so we might be able to just remove them... [1]: https://www.haiku-os.org/legacy-docs/bebook/BFilePanel_Overview.html The Be Book [1] states that these are supposed to be C functions, but the comment (see diff) said they were deprecated, and the fact that they were in a .cpp file (and I checked with "nm") made them C++ functions. I can't recall any applications failing to start because these symbols were unresolved, so we might be able to just remove them... [1]: https://www.haiku-os.org/legacy-docs/bebook/BFilePanel_Overview.html

"git blame" indicates they've been here since Tracker was imported into the tree, and a single paragraph explaining their existence just states they are more efficient/faster than the ones in BString due to running simple checks before calling str*cmp. If there is (still) such a performance problem in our BString, we should fix it there and not use hacky workarounds. I didn't notice any difference in speed when using Tracker with this patch; however, I'm on a reasonably fast machine. "git blame" indicates they've been here since Tracker was imported into the tree, and a single paragraph explaining their existence just states they are more efficient/faster than the ones in BString due to running simple checks before calling str*cmp. If there is (still) such a performance problem in our BString, we should fix it there and not use hacky workarounds. I didn't notice any difference in speed when using Tracker with this patch; however, I'm on a reasonably fast machine.

Since zip has been outsourced, it's possible to loose it when upgrading, in which case ZOM went busylooping without noticing the thread actually never started. At least now it says "failed to create the archive". Maybe it should try to install zip? Since zip has been outsourced, it's possible to loose it when upgrading, in which case ZOM went busylooping without noticing the thread actually never started. At least now it says "failed to create the archive". Maybe it should try to install zip?

Found by PVS-Studio developer Svyatoslav Razmyslov. Also update my email address. Found by PVS-Studio developer Svyatoslav Razmyslov. Also update my email address.