Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose OCaml version in C headers #6406

Closed
vicuna opened this issue May 8, 2014 · 11 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented May 8, 2014

Original bug ID: 6406
Reporter: @whitequark
Assigned to: @damiendoligez
Status: closed (set by @damiendoligez on 2014-07-21T20:40:05Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.02.0+dev
Fixed in version: 4.02.0+dev
Category: runtime system and C interface
Tags: patch, junior_job
Monitored by: @gasche

Bug description

I was specifically bitten by this commit: 05100e5#diff-f940572c32e55a7e40e7f693deea4c7bR42

Which changed, as far as I understand, a documented public API in an incompatible way between minor versions. This is horrible on its own, but the fact that there is no way to detect OCaml version in the C code to disambiguate makes it also impossible to work around.

File attachments

@vicuna

This comment has been minimized.

Copy link
Author

commented May 8, 2014

Comment author: @gasche

The documentation/specification
http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html
says:

caml_alloc(n, t) returns a fresh block of size n with tag t.
If t is less than No_scan_tag, then the fields of the block
are initialized with a valid value in order to satisfy
the GC constraints.

Which "valid value" is used is not specified in the documentation, so I don't think it was correct to rely on a precise choice of initialization value in the first place.

Could you explain the ctypes use-case? I had a glimpse of the discussion but that was quite cryptic to someone not familiar with the implementation.

@vicuna

This comment has been minimized.

Copy link
Author

commented May 8, 2014

Comment author: @whitequark

You do have a point. Still, the rest of my argument stands.

The idea is that an OCaml callback fills some parts of an Obj.t array, and leaves some intact. The C code would then detect filled-in parts.

@vicuna

This comment has been minimized.

Copy link
Author

commented May 9, 2014

Comment author: @mshinwell

I agree with Gabriel. I'm not sure it's a good idea to rely on which particular initializer is used.

Exposing a version string seems sensible.

@vicuna

This comment has been minimized.

Copy link
Author

commented May 9, 2014

Comment author: @whitequark

A string is nearly impossible to perform comparisons on; how about OCAML_MAJOR OCAML_MINOR OCAML_PATCH, and in addition OCAML_VERSION that has the previous concatenated. That's how I usually seen it done.

E.g. for 3.12:

OCAML_MAJOR = 3
OCAML_MINOR = 12
OCAML_PATCH = 00
OCAML_VERSION = 31200L

For 4.01.00:

OCAML_MAJOR = 4
OCAML_MINOR = 01
OCAML_PATCH = 00
OCAML_VERSION = 40100L

This way you have both conveniently separated version parts and a way to compare them... e.g. #if OCAML_VERSION >= 40200L

@vicuna

This comment has been minimized.

Copy link
Author

commented May 16, 2014

Comment author: @damiendoligez

A good idea, but isn't it overkill to make it a long int? I doubt we'll ever reach OCaml version 400000.00.0

@vicuna

This comment has been minimized.

Copy link
Author

commented May 16, 2014

Comment author: @whitequark

Hm, I think I cargo-culted the L suffix from the C-internal definitions, where you have conditions like "#if STDC_VERSION > 199900L". Not sure whether it's actually needed or it's some obscure leftover.

@vicuna

This comment has been minimized.

Copy link
Author

commented Jun 19, 2014

Comment author: dinosaure

I try to complete this issue with: #72

@vicuna

This comment has been minimized.

Copy link
Author

commented Jul 16, 2014

Comment author: @damiendoligez

I want to change a few things before I apply this patch or the github one.

Do you have a strong preference for the format of the OCAML_VERSION integer (i.e. decimal as here or binary as in the github patch)? I'd rather use decimal.

@vicuna

This comment has been minimized.

Copy link
Author

commented Jul 16, 2014

Comment author: @whitequark

Definitely decimal. Versions are in decimal, after all, it's just a form of fixed point. Also, I've never ever seen version constants in hex.

@vicuna

This comment has been minimized.

Copy link
Author

commented Jul 17, 2014

Comment author: dinosaure

It is done at your convenience. :)

@vicuna

This comment has been minimized.

Copy link
Author

commented Jul 21, 2014

Comment author: @damiendoligez

Patch modified and applied in 4.02 (commit 15016) and trunk (commit 15017).

@vicuna vicuna closed this Jul 21, 2014

@vicuna vicuna added this to the 4.02.0 milestone Mar 14, 2019

@vicuna vicuna added the bug label Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.