See test102.str and test103.str

---

main =
Some(“Hey”)

foo =
?f
; !f#([]){1, 2, 3}
———————————————–

f should have a String, but it is not.

The resulting C code will look like:

t = (ATerm) SRTS_setAnnotations(SSL_mkterm(j_27, (ATerm) ATinsert(ATempty, term_47)), (ATerm) ATinsert(ATempty, term_47));

In this code fragment the result of SSL_mkterm is not checked for NULL, which causes the SRTS_setAnnotations to produce the segmentation fault.

Submitted on 24 August 2006 at 22:52

STR-626, lennartkats:
It seems that the following still segfaults:

---

main =
Some(“Hey”);
?f;
!f#([]){1, 2, 3};
debug
———————————————-

Here, I inlined the foo strategy, which probably interacts with the bound variable detection.

STR-626, lennartkats:
Seems there was a minor copy/paste error in the last fragment; it should start with !Some(“Hey”). Still segfaults though.

STR-626, lennartkats:
Note that test103 actually succeeds because this bug is still present:

---

main =
Some(“Hey”)

foo =
?f
; rules(Foo : f#(_) -> [])
———————————————-

In the generated code, an illegal f#(_) dummy term is constructed and then passed to dr-set-rule.

Note that from a language perspective, it’s probably a good thing that this test succeeds; rules(Foo: -> []) also succeeds.

STR-626, lennartkats:
I fixed this; all generic term construction builds now have a NULL check. After discussing this with Eelco, we decided that the test103 case (having a bad generic term as a dynamic rule pattern) would not succeed but causes a failure as well.

STR-626, rbvermaa:
Test

STR-626, rbvermaa:
Last test… really!