On Mon, 2010-03-01 at 17:28 +0100, Stephan Bergmann wrote: > On 02/26/10 14:32, Terrence Enger wrote: > > I am looking at issue 109146 "Assertion: Error: seekEntry() Bad map ..." > > <http://www.openoffice.org/issues/show_bug.cgi?id=109146>. It just > > happens to be the first assertion that I saw triggered in my first > > non-product build.
> This issue is probably a bad choice to write a test for (at least a bad > choice for starters), for at least two reasons: Just my luck to pick an odball. <whine>Mummy, the computer is picking on me.</whine> The assertion itself is so easy to fix, that I figured I should do more. I fear now that I am am using more of your time than the problem is worth. Should I move on to something else? > > - Checking that an assertion fires is not easy. (It will become easier > when <http://qa.openoffice.org/issues/show_bug.cgi?id=109142> "Let > assertions abort" is fixed, if you assume that observing an abort > implies a fired assertion.) Er, yes. I was not even going to think about this until I had seen the assertion fire on the screen. And there is lots I have to do before that happens. Conspicuously, the test case has to load the library with the assertion and I-know-not-how-much-more beside. Meanwhile, the application defines MediaTypeEntry at file scope. So, there is no #include file to provide the definition. I may end up having to learn more than I want to know about the build system. And these are just the issues that come to mind before I try to do anything. > > - The DBG_ASSERT expression in the issue is wrong, whether or not it > fires depends on factors outside the C++ standard. It is generally not > possible to write standard C++ code that reliably causes the assertion > to fire or not to fire. (As you noted already. However, note that this > is not about stack variables, but about string literals in a library's > (read-only) data segment.) I was thinking of provoking the incorrect assertion by calling seekEntry() with a second parameter set up by something like ... MediaTypeEntry badMte[ 2 ] = { { " ", 0, " " }, { " ", 0, " " } }; char str1[ 6 ], str2[ 6 ]; if( str1 < str2 ) { strcpy( str2, "alpha" ); badMte[ 0 ].m_pTypeName = str2; strcpy( str1, "bravo" ); badMte[ 1 ].m_pTypeName = str1; } else { strcpy( str1, "alpha" ); badMte[ 0 ].m_pTypeName = str1; strcpy( str2, "bravo" ); badMte[ 1 ].m_pTypeName = str2; } I forget whether the comparison above is undefined or implementation-defined according to the standard. This code is not even compiled, let alone tested, but still it might succeed in provoking the assertion on quite a few platforms. The addresses of literal strings are a bit different in that we know that some platforms use different placement strategies. For all I know, different compiler options could change placement of literals. Of course, the corrected assertion will take this in stride. > > > That same test will have to cast away constness of > > MediaTypeEntry::m_pTypeName, and that is a bad thing to do. But I am > > *trying* to screw things up. Does that give me a pass? > > Why would you need to cast away constness? Because my crossed eyes saw "const" in the wrong place when I was reading the definition of MediaTypeEntry. Does that cut it as an excuse? Cheers, Terry. > > -Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
