Apache OpenOffice (AOO) Bugzilla – Issue 798
OpenOffice uses deprecated C++ not accepted by MIPSpro (-LANG:std) or gcc 3.0
Last modified: 2003-12-06 14:52:32 UTC
OpenOffice uses code that issues warning 1440 "The initial value of a reference to a non-const must be an lvalue." If I add -LANG:std it converts this warning into error 1262 "No instance of constructor "InfoString::InfoString" matches the argument list." I have no idea what MIPSpro's problem with this code is as yet however here is the test case: % cat hello.cxx class ByteString { public: ByteString (); ByteString ( ByteString &s ); private: int i; }; ByteString::ByteString () { i = 0; } ByteString::ByteString ( ByteString &s ) { i = 5; } class InfoString : public ByteString { public: InfoString ( ByteString &s ): ByteString ( s ) {;} }; int func ( InfoString &i ) { return 0; } int main() { func ( InfoString ( ByteString () ) ); } % gmake hello1 CC -o hello1 hello.cxx cc-1440 CC: WARNING File = hello.cxx, Line = 29 The initial value of a reference to a non-const must be an lvalue. func ( InfoString ( ByteString () ) ); ^ cc-1440 CC: WARNING File = hello.cxx, Line = 29 The initial value of a reference to a non-const must be an lvalue. func ( InfoString ( ByteString () ) ); ^ % gmake hello2 CC -LANG:std -o hello2 hello.cxx cc-1262 CC: ERROR File = hello.cxx, Line = 29 No instance of constructor "InfoString::InfoString" matches the argument list. The argument types are: (ByteString). func ( InfoString ( ByteString () ) ); ^ 1 error detected in the compilation of "hello.cxx". gmake: *** [hello2] Error 2
Created attachment 182 [details] tools/source/fsys/dirent.cxx : Workaround to get it to compile
Created attachment 183 [details] tools/bootstrp/envset.cxx : Workaround to get it to compile
Created attachment 184 [details] tools/inc/simplecm.hxx : Workaround to get it to compile
Created attachment 185 [details] tools/bootstrp/iserver.cxx : Workaround to get it to compile
Created attachment 186 [details] tools/bootstrp/mkcreate.cxx : Workaround to get it to compile
Created attachment 187 [details] tools/bootstrp/setsolar.cxx : Workaround to get it to compile
Created attachment 188 [details] tools/bootstrp/updmake.cxx : Workaround to get it to compile
Created attachment 203 [details] inet/source/core/ldapmsg.cxx : Could be the same problem by the looks of it
irix issue, sent to porting
Looking at just the patches, they really confuse me. I'll check them together with the source...
Wasnt much fun making those patches either. The essense of the problem is probably close to many other the other -LANG:std bugs, in that this code is typical, but not standard (yet to verify this)? If you look at my hello.cxx, the standards issue could be that ByteString () could also (when you look under the hood at the 'c' ) be a function pointer? If this is so then simple instantiation without a declaration becomes scary code. I hope the MIPSpro compiler group will be able to help me determine why - LANG:std turns this warning into an error.
This could also have something to do with the String class, as I am having difficulty in the 627B tree with String and UniString.
Created attachment 225 [details] sal/inc/rtl/ustring : Patch to ensure compiler finds class String
Created attachment 226 [details] sal/inc/rtl/string.hxx : : Patch to ensure compiler finds class ByteString
These two latest patches are actually a separate problem which could still yet be related, and hence all the above patches are still required. These two however do not modify code in any way, just make it more precise.
These two are indeed two different problems, and this latter problem is deeper than first thought, so I have taken it over to bug 850.
ustring fix applied in 1.5.2.1 string.hxx fix applied in 1.4.2.1 dirent.cxx fix applied in 1.5.10.1 simplecm.hxx fix applied in 1.5.6.1 iserver.cxx fix applied in 1.2 mkcreate.cxx fix applied in 1.6.4.1 setsolar.cxx fix applied in 1.2 updmake.cxx fix applied in 1.5.6.1 ldapmsg.cxx fix applied in 1.2.2.1
Sander, These were all just workarounds, and not intended for the tree. As per my first post to this bug, the compiler knows how to compile this code, its just choosing not to when I use -LANG:std . I believe the correct solution here is to get the compiler to like the code, otherwise its hundreds of patches, and somehow restricting the programming practises that created the problem. The last two fix the lack of precision which has been moved to bug 850 . I am currently looking for other code which could create the same problem as was found in unoidl. I think we should also pull back out these two, as preceeding the #define 'String' with :: seems incorrect. The correct solution would be to change solar.h to something like #define String ::UniString
I have recently found that gcc 3.0, even with -fpermissive , treats this code in the same fashion as MIPSpro. --- Using 2.95.3 % g++ -c -fpermissive -o hello hello.cxx hello.cxx: In function `int main()': hello.cxx:29: warning: initialization of non-const reference type `class ByteString &' hello.cxx:29: warning: from rvalue of type `ByteString' hello.cxx:21: warning: in passing argument 1 of `InfoString::InfoString(ByteString &)' hello.cxx:29: warning: initialization of non-const reference type `class InfoString &' hello.cxx:29: warning: from rvalue of type `InfoString' hello.cxx:24: warning: in passing argument 1 of `func(InfoString &)' Using 3.0 % g++ -c -fpermissive -o hello hello.cxx hello.cxx: In function `int main()': hello.cxx:29: no matching function for call to `InfoString::InfoString(ByteString)' hello.cxx:19: candidates are: InfoString::InfoString(InfoString&) hello.cxx:21: InfoString::InfoString(ByteString&)
Hi John, since more and more compiler treat this as an error (as mandated by the TC++PL §5.5 and §10.4.10) I'll write an article on dev@openoffice.org that this kind of code must be avoided. Quite a few API's use references where they should use const references which leads to this kind of broken code. I would expect that we'll see the dreaded "non const reference initializer must be lvalue" problem for a while until everyone gets it. Heiner
What compilers still accept this? Can they be forced to not accept it?
It would seem like these did not make the 632 branch. Both attachment 184 [details] and 182 were required for me to complete the bootstrap.
Merged to HEAD and tagged as OO633 the patches that were missing from: * tools/source/fsys/dirent.cxx * tools/inc/simplecm.hxx * tools/bootstrp/updmake.cxx * inet/source/core/ldapmsg.cxx Unfortunately version skew in future snapshots is stillpossible, but I'll try to check against it
Regarding 'inet/source/core/ldapmsg.cxx' I reverted the proposed change. I really do mean '*&' and not '*' here. Please don't break code because of a broken compiler. The issue in question seems to be a conflict between 'const_cast' and 'lvalue'. My new solution should keep both, the code's logic and the compiler happy.
Sorry Matthias, this must have been a typo ... for removing the & was not the solution ... the solution was to make the code consistent. If OpenOffice was to use <iostream.h> instead of <iostream>, MIPSpro would not have a problem, and I wouldnt have to create these patches. By no means is the compiler broken ... it just expects code to be consistent. From what I have been told by Heiner, this will also be required by the new SUN compiler. It is also expected by gcc 3.0, and I have yet to find how to get gcc 3.0 to play nice with OpenOffice code.
Well, most probably it's me to say sorry, not you. Obviously there should have been some smiley close to the words 'broken compiler'. I never meant to criticize your work, which I think you're doing well. And I fully agree with you and Heiner, that there is a considerable amount of code that needs to be adapted to meet today's standards. But I also feel, that this process needs to be a collaborative one, i.e. also involving the responsible developers, instead of just Sander commiting patches.
I agree 100%. As I am also the IRIX maintainer of Mozilla, I feel that much of the process behind Bugzilla is missing from IssueZilla. The process of review & super-review would have caught my typo, and should also have informed you of the likelyhood this Issue would impact your code.
*** Issue 805 has been marked as a duplicate of this issue. ***
Verifying issue. Please close this.
The MipsPro compiler is more flexible now... closing