Summary: | CharacterColor.h != and == implementation causing alignment trap on ARM (and probably other) processors (x86 not affected) | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | Alessandro Briosi <tsdogs> |
Component: | general | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Alessandro Briosi
2008-03-31 00:26:18 UTC
Forgot to mention the file: File is CharacterColor.h Hi, I didn't write that code myself but it seems to me that it is unnecessary to have them at all. Alignment problem aside, the operator==() and operator!=() methods are equivalent to the built-in defaults which the compiler generates. > Alignment problem aside, the operator==() and operator!=() methods
> are equivalent to the built-in defaults which the compiler generates.
Sorry, moment of stupidity, I was thinking of operator=(). An alterative would be to use memcmp() in operator==() and then define operator!=() as !operator==().
SVN commit 792018 by knight: Re-write CharacterColor::operator==(), CharacterColor::operator!=(). Previous implementation caused memory alignment trap on ARM. BUG:160137 M +2 -5 CharacterColor.h WebSVN link: http://websvn.kde.org/?view=rev&revision=792018 SVN commit 792019 by knight: Compare CharacterColor members explicitly rather than using memcpy for clarity. CCBUG: 160137 M +4 -1 CharacterColor.h WebSVN link: http://websvn.kde.org/?view=rev&revision=792019 |