Unclear semantics of [@@noalloc] #7655
Comments
|
Comment author: @xavierleroy Yes, [@@noalloc] and several other function attributes such as [@@unboxed] apply only in native code. Feel free to suggest a better wording for the reference manual to make this point clearer. |
|
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. |
Original bug ID: 7655
Reporter: @mmottl
Assigned to: @gasche
Status: resolved (set by @gasche on 2017-10-14T23:43:18Z)
Resolution: fixed
Priority: normal
Severity: text
Version: 4.05.0
Fixed in version: 4.06.0 +dev/beta1/beta2/rc1
Category: documentation
Monitored by: @gasche @mmottl
Bug description
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.
The text was updated successfully, but these errors were encountered: