Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 80178 - SRPMS: ill-formed code - comparing enum with char *
Summary: SRPMS: ill-formed code - comparing enum with char *
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: koffice
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-21 08:32 UTC by Sysoltsev Slawa
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version: 1.4.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-16 16:25:02 UTC


Attachments (Terms of Use)
Patch, which fixes decribed problem (deleted)
2002-12-21 08:37 UTC, Sysoltsev Slawa
no flags Details | Diff

Description Sysoltsev Slawa 2002-12-21 08:32:36 UTC
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.

Comment 1 Sysoltsev Slawa 2002-12-21 08:37:03 UTC
Created attachment 88841 [details]
Patch, which fixes decribed problem

Comment 2 Ngo Than 2006-01-16 16:25:02 UTC
it's fixed in koffice-1.4.2 in FC4.


Note You need to log in before you can comment on or make changes to this bug.