Hi, cffi-devel
As an addition, I tested your code on LispWorks 5.1.1 (64-bit Linux
Edition), seem there's no limit on stack size, though LispWorks has a
default value, when it reached, I got a prompt to decide whether
increase it (by 50%/300%).
Some outputs when I break the run manually (and LispWorks fine, no
error):
[60114] #<Pointer to type :BYTE = #x2AAB276F38C0>: total allocated
3,077,836,800
[60115] #<Pointer to type :BYTE = #x2AAB277000D0>: total allocated
3,077,888,000
[60116] #<Pointer to type :BYTE = #x2AAB2770C8E0>: total allocated
3,077,939,200
P.S. By looking at LispWorks FLI, I cannot find any option in FLI:WITH-
FOREIGN-STRING. Don't know how to control a foreign string be
allocated in heap or stack...
--binghe
Many Lisps seem to operate with much smaller stacks. Here's the
test I
used:
(defconstant +size+ (* 50 (expt 2 10))) ; 50 KB
(defun test ()
(labels ((ek (n)
(cffi:with-foreign-pointer (p #.+size+)
(loop for i below +size+
do (setf (cffi:mem-ref p :char i) 0))
(format t "[~A] ~A: total allocated ~:D~%"
n p (* +size+ n))
(ek (1+ n)))))
(ek 1)))
(compile 'test)
SBCL: ~2 MB followed by "the party is over."
CCL: ~2 MB followed by a segfault.
CLISP: 8 MB followed by a graceful stack overflow.
Allegro: ~4 MB followed by a graceful stack overflow.
(used 40 KB chunks otherwise Allegro refused to do stack allocation)
This is on linux/amd64 (but I think my copy of Allegro is a 32-bit
version). Hopefully my test is not (too) bogus.
Given this, I'd think that making stack allocation be the default and
heap allocation an option would be beneficial. If you really don't
like it, making the default a compile-time option would be better
than
mandating an allocation policy, I think.
Since the size argument has to be known at compile-time (IIRC), maybe
WITH-FOREIGN-POINTER can look at that size and decide if it should
fallback to heap allocation.
CCL and Allegro do this. SBCL and CLISP don't. If we did that check
ourselves we'd get more consistent behaviour across the various
Lisps we
support and that might reduce the likelihood of overflowing the stack
with big objects, particularly strings. Also, it would be nice if
SBCL
and CCL could handle stack overflows without crashing.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel