Issue 31479

Summary: basic/inc/testtool.hxx #defines conflict with basic/inc/sbdef.hxx enum
Product: General Reporter: fa <dan>
Component: codeAssignee: fa <dan>
Status: CLOSED FIXED QA Contact: issues <issues.openoffice.org>
Severity: trivial    
Priority: P3 CC: caolanm, gregor.hartmann, issues, jens-heiner.rechtien, nesshof
Version: 680   
Target Milestone: OOo 2.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation on: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 28294    
Attachments:
Description Flags
Increase explicit size of enum to cover all values none

Description fa 2004-07-14 16:22:34 UTC
gcc 3.4 does not allow an enum type to be assigned a value outside its declared
range.  In sbdef.hxx, we have:

enum SbTextType {
	SB_KEYWORD = 1,
	SB_SYMBOL,
	SB_STRING,
	SB_NUMBER,
	SB_PUNCTUATION,
	SB_COMMENT
};

In testtool.hxx, additional values are defined, but using #define and they are
not part of the enum.  This is illegal in C++ with gcc 3.4:

#define TT_KEYWORD	((SbTextType)100)
#define TT_REMOTECMD	((SbTextType)101)

I've looked over the sources, and it seems that the testtool.hxx types are not
widely used (used only in 3 of 4 files).  I don't think the "clean" solution is
to add the testtool.hxx ones to the SbTextTypes enum because they are clearly
not "normal" code.  However, I'd like insight into how to fix this problem.  Any
ideas?
Comment 1 fa 2004-07-14 16:31:57 UTC
target -> 2.0
Comment 2 fa 2004-07-14 17:04:59 UTC
Created attachment 16465 [details]
Increase explicit size of enum to cover all values
Comment 3 fa 2004-07-14 17:05:49 UTC
Does the patch seem correct to everyone?  It fixes the problem, but I still
think the correct solution is to not have the extra TT_* values and cast them to
SbTextType.
Comment 4 Olaf Felka 2004-07-15 08:55:39 UTC
of: Please have a look. Is the target ok?
Comment 5 Martin Hollmichel 2004-07-15 09:28:56 UTC
reassign back ;)
Comment 6 jens-heiner.rechtien 2004-07-15 14:22:33 UTC
Committed to CWS gcc340fixes01
Comment 7 jens-heiner.rechtien 2004-07-15 14:30:44 UTC
HR->GH: Dans patch is correct and will do the job, but this really needs a
thorough cleanup.
Comment 8 Olaf Felka 2004-07-15 14:49:04 UTC
of @ mh: Please enlighten me: Why is this 'component framework'? What has this
to do with the office framework?
Comment 9 Martin Hollmichel 2004-07-15 15:12:52 UTC
mh->of: in this case it is in fact not easy. The basic project is located in the
CVS in the Script project which was declared as "dead". So usually you take the
CVS Project as corresponding component in IZ, and for basic in this case we take
framework as an exception.
In every case this is not an porting issue but has to be addessed by the
developer directly. In this special case the best way would have been that Dan
already had assigned this issues to himself at submit time, so we both wouldn't
have been involved at all :).
Comment 10 Olaf Felka 2004-07-16 08:22:42 UTC
of @ mh: Got it. :-)
Comment 11 fa 2004-07-20 12:31:16 UTC
I wanted clarification from the original Sun developer or someone familiar with the code to tell me why 
the SbTextType was getting used in this way...  I did not feel completely comfortable with the patch and 
wanted to make sure the original intent was correct, and that this problem was not somehow a coding 
mistake or mis-design.
Comment 12 jens-heiner.rechtien 2004-08-11 17:32:39 UTC
closing ...