RE: [Caml-list] external function with arity > 5 and "noalloc"

[David Allsopp <dra-news@metastack.com>]

Florent Monnier wrote:
> Hi,
> 
> I'm not sure if this behavior is a bug or not.
> Here a given function defined in a stub:
> 
> cat > bind.ml <<EOF
> external f :
>   v1:int ->
>   v2:int ->
>   v3:int ->
>   v4:int ->
>   v5:int ->
>   v6:int -> int
>   = "bind_f"
>     "bind_f_bc"
>     "noalloc"
> EOF

The naming you're using here implies you've got these the wrong way around - the bytecode stub comes first (I'm assuming that's what _bc means) - see 19.1.2 in the manual.

> if compiles fine with all warnings on:
> ocamlopt -c -w +A -warn-error +A bind.ml
> 
> if will also compile fine with:
>   = "bind_f"
>     "bind_f_bc"
> 
> if I put only:
>   = "bind_f"
> 
> I get a compilation error, which is what I expected:
> 
> ocamlopt -c -w +A -warn-error +A bind.ml
> 
> File "bind.ml", line 2, characters 2-75:
> Error: An external function with more than 5 arguments requires
>   a second stub function for native-code compilation
> 
> 
> But now if I write this way:
>   = "bind_f"
>     "noalloc"
> then I get no compile error anymore.

This isn't a bug - are you able to link the executable? What you've specified is an external f using a function bind_f for bytecode and noalloc for native code - unless there is a symbol noalloc knocking around somewhere in the runtime, I'd expect you to get a linking error with ocamlopt and either a linking error or a runtime segfault with ocamlc (because of using bind_f not bind_f_bc).

"noalloc" as a string rather than a keyword is a bit of a hack (though I'm sure there's a logical reason it was done that way - although it does just look a teensy bit lazy as it means the grammar for external is simply a string list!). What is a bug is that noalloc isn't mentioned in Chapter 19 of the manual (similarly for "float" which can also be specified).


David