Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Unclear semantics of [@@noalloc] #7655
Original bug ID: 7655
The manual does not seem to specify the behavior of external function declarations with the [@@noalloc] attribute if both a byte and native code entry point are declared. Though one would typically expect both entry points to have the same allocation behavior, this is eminently not the case when the function also declares that it returns unboxed values.
E.g. many numeric functions in Pervasives return unboxed doubles, which have to be explicitly allocated for byte code but not for native code. The functions are nevertheless declared with [@@noalloc]. I guess the byte code interpreter always ignores this attribute, otherwise the current Pervasives implementation would not be safe.
I think the expected behavior of [@@noalloc] with byte and native code should be documented in the C-interface section of the manual.
Comment author: @mmottl
Indeed, I just realized that the main section has a small note that it only applies to the native code compiler. But in its subsections (about unboxing and direct C-calls respectively) the text only refers to "the OCaml compiler". The note at the beginning of the main section is easy to miss. I knew that unboxing / untagging would only work with the native code compiler, but I always mistakenly believed that "noalloc" applied to byte code stubs, too.
I have just submitted a pull request that hopefully improves the wording in subsections.