Closed
Conversation
MisterDA
force-pushed
the
stricter-c99-primitives-void
branch
from
f3fc466 to
d013f87
Compare
rename the type of the accumulator of fold functions to 'acc
error messages: use de Bruijn indices for identifier disambiguation
Sort the index of modules in the API documentation in the following order - text documentation - non-internal modules - internal modules In each subcategory, the modules are sorted in alphabetical order
documentation: sort modules alphabetically fixes ocaml#11857
The generation of the file listing of primitives now depends on the C files and the generator script. Rather than echo'ing or not the rule prerequisite, introduce an explicit rule for `primitives.new`.
Fedora is considering moving all its packages to C99 and enabling stricter C99 warnings. OCaml has already moved to a compiler requiring C11 features, let's enable these warnings on GCC-compatible compilers. Some of the warnings on the following article are already covered by -Wall and -Werror. Reference: [Modernizing Fedora's C code][1]. [1]: https://lwn.net/Articles/913505/
It is always possible to cast a function pointer to another function
pointer type, and cast again to the original type before calling the
pointed function. I pick the base
typedef value (*c_primitive)(void);
to store the functions in the array, and cast them back in the
interpretor according to the arity described by the opcode.
Some reference:
- [Function pointers in C][1]
- [Function pointer casts][2]
[1]: https://frama-c.com/2013/08/24/Function-pointers-in-C.html
[2]: https://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
The primitives function pointers can be stored as simple void
pointers:
> Note that ISO C forbids casting a function pointer to type void *,
> but we've been doing this for a very long time, and all C compilers
> that I know of are happy with this.
(comment by Xavier Leroy)
This is documented by C11 Standard J.5.7, Function pointer casts.
The prototypes in `prims.c` and the headers differ, but:
> On the one hand, it's not legal C11 to declare value f(void) a
> function f that is defined in another compilation unit as value
> f(value), say; while I think it is correct to declare it value f(),
> like we currently do. On the other hand, this is no worse than the
> many other "not legal C11" things we already do.
(comment by Xavier Leroy)
MisterDA
force-pushed
the
stricter-c99-primitives-void
branch
from
d013f87 to
484021b
Compare
MisterDA
pushed a commit
that referenced
this pull request
Jul 25, 2024
…l#13294) The toplevel printer detects cycles by keeping a hashtable of values that it has already traversed. However, some OCaml runtime types (at least bigarrays) may be partially uninitialized, and hashing them at arbitrary program points may read uninitialized memory. In particular, the OCaml testsuite fails when running with a memory-sanitizer enabled, as bigarray printing results in reads to uninitialized memory: ``` ==133712==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x4e6d11 in caml_ba_hash /var/home/edwin/git/ocaml/runtime/bigarray.c:486:45 #1 0x52474a in caml_hash /var/home/edwin/git/ocaml/runtime/hash.c:251:35 #2 0x599ebf in caml_interprete /var/home/edwin/git/ocaml/runtime/interp.c:1065:14 #3 0x5a909a in caml_main /var/home/edwin/git/ocaml/runtime/startup_byt.c:575:9 #4 0x540ccb in main /var/home/edwin/git/ocaml/runtime/main.c:37:3 #5 0x7f0910abb087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef) #6 0x7f0910abb14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef) #7 0x441804 in _start (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x441804) (BuildId: 7a60eef57e1c2baf770bc38d10d6c227e60ead37) Uninitialized value was created by a heap allocation #0 0x47d306 in malloc (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x47d306) (BuildId: 7a60eef57e1c2baf770bc38d10d6c227e60ead37) #1 0x4e7960 in caml_ba_alloc /var/home/edwin/git/ocaml/runtime/bigarray.c:246:12 #2 0x4e801f in caml_ba_create /var/home/edwin/git/ocaml/runtime/bigarray.c:673:10 #3 0x59b8fc in caml_interprete /var/home/edwin/git/ocaml/runtime/interp.c:1058:14 #4 0x5a909a in caml_main /var/home/edwin/git/ocaml/runtime/startup_byt.c:575:9 #5 0x540ccb in main /var/home/edwin/git/ocaml/runtime/main.c:37:3 #6 0x7f0910abb087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef) #7 0x7f0910abb14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef) #8 0x441804 in _start (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x441804) (BuildId: 7a60eef57e1c2baf770bc38d10d6c227e60ead37) SUMMARY: MemorySanitizer: use-of-uninitialized-value /var/home/edwin/git/ocaml/runtime/bigarray.c:486:45 in caml_ba_hash ``` The only use of hashing in genprintval is to avoid cycles, that is, it is only useful for OCaml values that contain other OCaml values (including possibly themselves). Bigarrays cannot introduce cycles, and they are always printed as "<abstr>" anyway. The present commit proposes to be more conservative in which values are hashed by the cycle detector to avoid this issue: we skip hashing any value with tag above No_scan_tag -- which may not contain any OCaml values. Suggested-by: Gabriel Scherer <gabriel.scherer@gmail.com> Signed-off-by: Edwin Török <edwin.torok@cloud.com> Co-authored-by: Edwin Török <edwin.torok@cloud.com>
MisterDA
pushed a commit
that referenced
this pull request
Sep 19, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.