Choosing safe-string at configure time#687
Conversation
|
Any opinion on this proposal? I think we need to move forward with the safe-string migration, and this tiny step might help, so let's have it in 4.04 unless someone is against. |
|
A probably naive remark, but simply ignoring "-unsafe-string" with a warning sounds quite bold at this point. Would it makes sense to rather make "-unsafe-string" an error at this point? I would imagine that if a library/executable does take the time to precise the "-unsafe-string" option it has a good reason to do so and should not be compiled with only a simple, and quite easy to miss, warning. |
|
I agree with @Octachron that making As an OCaml user I'd like to use this configure option in 4.04. I try to use the option in my projects (along with its sequence and format counterparts) but don't always remember to do so when setting them up. The fewer steps to remember for future-proof and clean code the better. |
|
The rationale for make But this is indeed dubious, and since the default is still So I'll turn that into a proper error. |
9960a9e to
c6640ef
Compare
|
Does anyone want to review this? |
| error (Need_recursive_types(ps.ps_name, !current_unit)) | ||
| | Unsafe_string -> | ||
| if Config.safe_string then | ||
| error (Depend_on_unsafe_string_unit (ps.ps_name, !current_unit)); |
There was a problem hiding this comment.
Would this break existing code not using the new configure switch, if safe and unsafe modules are mixed? That seems like it could break a lot of code, even if it should have been broken already.
There was a problem hiding this comment.
The error is only raised when the system is configured with safe-string (this is Config above, not Clflags). So no, no risk (unless I somehow screwed it up).
There was a problem hiding this comment.
That makes sense - thank you for the explanation.
When configured with -safe-string, the OCaml tools will default to the safe-string mode and ignore -unsafe-string command-line arguments. This is intended to serve two purposes: - Facilitate the detection of packages that are not ready for -safe-string ready. (Perhaps with some OPAM switch?) - Enable some optimizations that assume that all linked units are compiled with -safe-string. Note: currently, there is no check that units compiled with an OCaml configured without -safe-string are not linked in.
This is used to prevent depending on a unit compiled with -unsafe-string when the compiler has been *configured* with -safe-string. This is not 100% bullet-proof, since the unsafe_string marker is not propagated transitively, so it is possible to "hide" it by going through an intermediate compilation unit compiled with -safe-string (with a compiled configure without -safe-string). But this should catch most cases of old files staying around produced by a compiler not configured with -safe-string.
5234ba6 to
9538a54
Compare
|
The asmcomp/staticalloc test is failing in this mode. Strings are not mutable anymore. I'm not sure how to write that part of the test now... |
|
The driver Makefile could pass the value of SAFE_STRING (from config/Makefile) to the test, so it could either test with |
|
This looks like the right solution |
Choosing safe-string at configure time
This PR adds a
-safe-stringflag to./configure. When the system is compiled in this mode, the compile-time option-safe-stringis implied, and-unsafe-stringis ignored (printing a warning on stderr). This is to serve two goals:-safe-string(e.g. through an OPAM switch).-safe-string. In particular, this PR enables sharing of string literals in a given compilation unit.Hopefully, this will give extra incentive to the community to move to
-safe-string.In addition to the configure flag, this PR also records in
.cmifile the safe/unsafe_string status. Currently, this is only used to fail when opening a.cmifile compiled in unsafe-string mode in a compiled configured in safe-string mode. This is not bullet proof as explained in the corresponding commit message. (We don't even check that the implementation is compiled in -safe-string when its interface is; we should probably do that.) A simple stronger alternative would be to use different magic numbers (as for flambda .cmx files), but the proliferation of different magic number for each version of OCaml become tedious (magic number are not really suited to encode orthogonal flags). One could also have a flag stored in .cmi and "inherited" automatically. But anyway, this is rather minor and only to protect people from their own mistake (forgetting to recompile a library already compiled in unsafe-string mode when switching to a compiler configured with safe-string ).(This is related to http://caml.inria.fr/mantis/view.php?id=7113.)