Erroneous primop return value counts cause interesting times

[GoogleCodeExporter]

How to trigger the problem?

owl-lisp e$ bin/ol
You see a prompt.
> (clock)
Segmentation fault: 11
owl-lisp e$ 

What is the expected output?

values of (clock)

What do you see instead?

Segfault

What version of the product are you using? On what operating system?

> *owl-version*
"0.1.7f"

Mac OSX 10.7.3 on x86_64 (Core i7)

Please provide any additional information below.

Original issue reported on code.google.com by doug.cur...@gmail.com on 29 Apr 2012 at 3:11

[GoogleCodeExporter]

Thanks! It reproduces here. Sounds like there is something wrong in primop 
return value checks. I'll have a look in the evening.

Original comment by aohelin on 29 Apr 2012 at 7:53

• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

There seem to be two issues: the clock primop is exposed at toplevel in 
addition to time-ms, which isn't much of a problem, but more generally primop 
return value counts aren't checked properly at compile time. Normal multiple 
value returns don't trigger this because they hit the usual argument count 
check code.

Leaving open for next spare hacking slot.

Original comment by aohelin on 29 Apr 2012 at 7:21

• Changed title: Erroneous primop return value counts cause interesting times
• Changed state: Started