Skip to content

Emphasize that Bigarray.int refers to the OCaml int type, and not the C int type#12298

Merged
Octachron merged 3 commits into
ocaml:trunkfrom
edwintorok:doc-bigarray
Jul 18, 2024
Merged

Emphasize that Bigarray.int refers to the OCaml int type, and not the C int type#12298
Octachron merged 3 commits into
ocaml:trunkfrom
edwintorok:doc-bigarray

Conversation

@edwintorok
Copy link
Copy Markdown
Contributor

This is already documented in 'element kinds', but I think it is worth emphasizing, because it can lead to bugs like yallop/ocaml-ctypes#744 if the C and OCaml types for 'int' are mixed up.

On Linux x86-64 they are of different sizes (8 bytes vs 4), and this can lead to memory corruption if one is not careful,
in fact the closest C type here would be size_t, and there is no bigarray that would map a C int* in a platform-independent way.

Comment thread stdlib/bigarray.mli Outdated
Comment thread stdlib/bigarray.mli Outdated
@edwintorok
Copy link
Copy Markdown
Contributor Author

Sorry, this PR must've gotten lost in my inbox. I've updated it now, I think it also needs the no-change-entry-needed label, unless you want me to add a Changes entry for it?

Comment thread stdlib/bigarray.mli Outdated
@Octachron
Copy link
Copy Markdown
Member

I would prefer if you added a Changes entry, documentation improvements are important improvements.

@edwintorok edwintorok force-pushed the doc-bigarray branch 2 times, most recently from c7d8731 to 8bee3b0 Compare July 15, 2024 12:05
edwintorok and others added 3 commits July 17, 2024 22:25
Signed-off-by: Edwin Török <edwin@etorok.net>
This is mentioned in the 'Element kinds' documentation, but that is not
visible anywhere in LSP documentation completions.
It is worth emphasizing this, because getting this wrong may lead to
memory corruption.

Suggested-by: Florian Angeletti <<florian.angeletti@inria.fr>>
Signed-off-by: Edwin Török <edwin@etorok.net>
Signed-off-by: Edwin Török <edwin.torok@cloud.com>
@edwintorok
Copy link
Copy Markdown
Contributor Author

I fixed the conflicts in Changes, I think the PR numbers are meant to be sorted in each section, so I kept this one as first in the 'Manual and documentation' section and moved 13295 last.

@Octachron Octachron merged commit 96afe93 into ocaml:trunk Jul 18, 2024
@Octachron
Copy link
Copy Markdown
Member

The ordering of Changes entries is not strictly enforced, but moving around the change entry looks fine.
Finally merged, thanks for your patience!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants