Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Make caml_named_value return a const value* #2293
Values can be passed from OCaml to C by registering them under a known name using
This patch changes the return type to
This patch requires minor code changes to make C stubs continue to compile cleanly (detailed below). As well as the change to the type of
Code changes in C stubs
There are two ways that
The second is by caching the returned pointer in a static variable:
With this patch, the second type of occurrence will cause a compiler warning ("assignment discards const qualifier", or something to that effect). This warning is non-fatal (unless compiling with
To avoid the warning, the declaration of
This change is compatible with all versions of OCaml: it is always safe to store a
To check whether all uses of
In OPAM, there are 1297 references to caml_named_value, of which 627 match the first pattern above (they dereference immediately as
I manually inspected all of the C++ source occurrences and a random sample of 10% of the C occurrences; every single one fit the second pattern above. After this patch, these occurrences will generate a warning until a
Edit: The occurrence count numbers above are all a bit too high (by ~20%), since my hacky script downloads the source of each package, despite the fact that many packages share the same source.
A minor side benefit of this change is that since the registered values can no longer be modified from C code, they can be registered with
I agree, in hindsight this would have been a better API. I'm still worried about the number of packages that this change might break. I'm afraid most packages will just ignore the warning or cast back to
No. I'm not expecting any existing code to do this, for the reasons you wrote.
In that case, an alternative would be to leave the function non-
I'd prefer a warning for new code, but perhaps that could be opt-in via some "strict mode"-type preprocess macro
I'm OK with this, but would be happier if the OPAM-wide testing could take place soon rather than at the last minute before releasing 4.09.