Issue 76838 - Bad code generated by cppumaker without -C or -L
Summary: Bad code generated by cppumaker without -C or -L
Status: CLOSED FIXED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: steffen.grund
QA Contact: issues@udk
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-02 09:24 UTC by Stephan Bergmann
Modified: 2009-07-20 15:22 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Changes to SRC680m211 cppumaker to reveal problems (2.55 KB, patch)
2007-05-02 09:25 UTC, Stephan Bergmann 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2007-05-02 09:24:21 UTC 
At least on SRC680m211, cppumaker without -C or -L generates that has two
errors.  See the attached cppumaker.patch:

- The change to test/cppumaker/makefile.mk is a hack so that calling dmake in
test/cppumaker tests cppumaker without -C.  (It would be good if test/cppumaker
could be changed so that it tests cppumaker in all three variants: -C, -L, and
none).

- That causes a failure as the generated headers contain identifiers containing
'<', ',', and '>'. The change to source/cppumaker/cpputype.cxx is a quick hack
to get that fixed just for now.

- Then, the new test added to test/cppumaker/test_codemaker_cppumaker.cxx shows
the second error: cppumaker emits calls to getCppuType for sal_Unicode, which
returns the type for sal_uInt16.
Comment 1 Stephan Bergmann 2007-05-02 09:25:18 UTC 
Created attachment 44800 [details]
Changes to SRC680m211 cppumaker to reveal problems
Comment 2 jsc 2007-05-15 15:31:03 UTC 
accepted
Comment 3 jsc 2007-07-19 12:33:26 UTC 
fixed on cws jsc18. The  code generation for -L is not changed and the test
still breaks because the test is not sufficient for this scenario. -L requires
an initialized UNO env with the correct rdb where the type info can be found.
The current test env doesn't support it appropriate. I have created a follow up
task #79785 to take care of this later. 

The other two options are adapted to use cpp:.UnoType<...>::get() directly
instead of getCppuType where possible.
Comment 4 steffen.grund 2007-07-25 12:06:32 UTC 
reassign
Comment 5 steffen.grund 2007-07-25 12:07:01 UTC 
tests work -> verified.
Comment 6 thorsten.ziehm 2009-07-20 15:22:46 UTC 
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues