Bug 80178
| Summary: | SRPMS: ill-formed code - comparing enum with char * | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Sysoltsev Slawa <vyatcheslav.sysoltsev> | ||||
| Component: | koffice | Assignee: | Than Ngo <than> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 8.0 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 1.4.2 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-01-16 16:25:02 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 88841 [details]
Patch, which fixes decribed problem
it's fixed in koffice-1.4.2 in FC4. |
Description of problem: Compiling koffice from source I'fo got such error: ellipse.cc(94): error: no operator "==" matches these operands operand types are: EStyle == const char [9] if(getFillStyle() == "FS_SOLID") ^ Looking into koffice-1.2-rc1/filters/kontour/latex/ellipse.cc I've found that there in line 94 you compare result of getFillStyle() function (enum EStyle type) with string "FS_SOLID" (note that FS_SOLID is member of enum EStyle). I'm sure you meant comparing with just FS_SOLID here and typed "" erroneously. That ill-formed code probably will cause some run-time bug. GNU C++ compiler accepts this code it due to row of typecasting (through QCString) without even warning, but it wrongs (see bug report #80177). Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. I'm afraid you won't be able to reproduce it, because current GNU C++ compiler accepts this ill-formed code without any issues; however you could use Intel compiler or possible other third-side compiler to reproduce this bug. Actual results: Succesfully compiled ill-formed code with possible run-time bug. Expected results: Succesfully compiled code without run-time bug. Additional info: I'll attach the patch which fixes problem I described.