Ekdohibs
/
ocaml
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

manual: fix missing escape characters in intf-c

master
octachron 2015-12-14 21:35:09 +01:00
parent 533e0cdd29
commit 7659a19c1d
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
manual/manual/cmds/intf-c.etex
View File

@ -1951,7 +1951,7 @@ OCaml compiler has no choice but to box "a.(i)" and "b.(i)" and unbox
the result of "foo". This results in the allocation of "3 * len" the result of "foo". This results in the allocation of "3 * len"
temporary float values. temporary float values.
Now if we annotate the arguments and result with "[@@unboxed]", the Now if we annotate the arguments and result with "[\@unboxed]", the
compiler will be able to avoid all these allocations: compiler will be able to avoid all these allocations:
\begin{verbatim} \begin{verbatim}
@ -1977,7 +1977,7 @@ CAMLprim value foo_byte(value a, value b)
\end{verbatim} \end{verbatim}
For convenicence, when all arguments and the result are annotated with For convenicence, when all arguments and the result are annotated with
"[@unboxed]", it is possible to put the attribute only once on the "[\@unboxed]", it is possible to put the attribute only once on the
declaration itself. So we can also write instead: declaration itself. So we can also write instead:
\begin{verbatim} \begin{verbatim}
@ -1996,7 +1996,7 @@ what C types should be used in correspondence:
Similarly, it is possible to pass untagged OCaml integers between Similarly, it is possible to pass untagged OCaml integers between
OCaml and C. This is done by annotating the arguments and/or result OCaml and C. This is done by annotating the arguments and/or result
with "[@@untagged]": with "[\@untagged]":
\begin{verbatim} \begin{verbatim}
external f : string -> (int [@untagged]) = "f_byte" "f" external f : string -> (int [@untagged]) = "f_byte" "f"
@ -2005,7 +2005,7 @@ external f : string -> (int [@untagged]) = "f_byte" "f"
The corresponding C type must be "intnat". The corresponding C type must be "intnat".
{\bf Note:} do not use the C "int" type in correspondence with "(int {\bf Note:} do not use the C "int" type in correspondence with "(int
[@untagged])". This is because they often differ in size. [\@untagged])". This is because they often differ in size.
\subsection{Direct C call} \subsection{Direct C call}
@ -2018,7 +2018,7 @@ For small functions that are called repeatedly, this indirection can
have a big impact on performances. However this is not needed if we have a big impact on performances. However this is not needed if we
know that the C function doesn't allocate and doesn't raise know that the C function doesn't allocate and doesn't raise
exceptions. We can instruct the OCaml compiler of this fact by exceptions. We can instruct the OCaml compiler of this fact by
annotating the external declaration with the attribute "[@@noalloc]": annotating the external declaration with the attribute "[\@\@noalloc]":
\begin{verbatim} \begin{verbatim}
external bar : int -> int -> int = "foo" [@@noalloc] external bar : int -> int -> int = "foo" [@@noalloc]