BZ #168: enableassertions/disableassertions command line handling wrong

Status fields:

creation_ts:2012-03-13 16:22
component:vm
version:default branch
rep_platform:All
op_sys:All
bug_status:RESOLVED
resolution:FIXED
reporter:stefan@complang.tuwien.ac.at
This happens only with GNU classpath. Running "make check" in tests/regression/assertion
yields:

eatest1: FAILED
--- ./enabled.output    2008-09-18 10:46:45.000000000 +0200
+++ enabled.thisoutput  2012-03-13 16:15:53.000000000 +0100
@@ -1 +1 @@
-Assertions enabled!
+Assertions disabled!
eatest2: FAILED
--- ./enabled.output    2008-09-18 10:46:45.000000000 +0200
+++ enabled.thisoutput  2012-03-13 16:15:53.000000000 +0100
@@ -1 +1 @@
-Assertions enabled!
+Assertions disabled!
[...]
esatest1: FAILED
--- ./disabled.output   2008-09-18 10:46:45.000000000 +0200
+++ disabled.thisoutput 2012-03-13 16:15:57.000000000 +0100
@@ -1 +1 @@
-Assertions disabled!
+Assertions enabled!
esatest2: FAILED

The command line handling for these options seems slightly off.

Comment #1 by zapster@complang.tuwien.ac.at on 2012-05-22 16:57:41

Created an attachment (id=77)
enableassertion fix

This patch should fix the enableassertion issues with `make check'. The real problem is
in GNU Classpath as there is currently no way to distinguish between normal assertions
and system assertions. The topic has been discussed on the Classpath ML [1] and a patch
was proposed [2] but it has not yet found its way into the upstream repository.

Although, this patch was designed to work with the Classpath patch it fixes the `make
check' issue even if the Classpath issue is not fixed.

[1]: http://developer.classpath.org/pipermail/classpath/2012-April/003195.html
[2]: http://developer.classpath.org/pipermail/classpath-patches/2012-April/006690.html

Comment #2 by stefan@complang.tuwien.ac.at on 2012-09-04 08:02:44

In 1.6.0.

Attachment id=77

date:2012-05-22 16:57
desc:enableassertion fix
type:text/x-patch
download:assert-fix.patch