From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 7A3057FA31 for ; Wed, 16 Jul 2014 13:38:30 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.01,671,1400018400"; d="asc'?scan'208";a="85412694" Received: from macabane.inria.fr ([128.93.8.160]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 16 Jul 2014 13:38:30 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_7D0AC3C1-53BE-4EC3-BD51-6BB6AC62247F"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Damien Doligez In-Reply-To: <1404558258.4384.16.camel@e130> Date: Wed, 16 Jul 2014 13:38:29 +0200 Cc: caml-list Message-Id: <98ACC054-7174-4A71-931B-C624D194C56A@inria.fr> References: <1404501528.4384.4.camel@e130> <1404558258.4384.16.camel@e130> To: Gerd Stolpmann X-Mailer: Apple Mail (2.1283) Subject: Re: [Caml-list] Immutable strings --Apple-Mail=_7D0AC3C1-53BE-4EC3-BD51-6BB6AC62247F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Gerd and OCaml users, First note that we are not breaking backward compatibility: you can always use the -unsafe-string flag to compile your dusty code. On 2014-07-05, at 13:04, Gerd Stolpmann wrote: > So my scenario is quite low-level: I/O, and C interfaces. As you said, bigarrays are the best suited for that kind of code. But that's not a good reason to make all strings as heavy as bigarrays. If you need bigarrays, by all means use bigarrays in your code, not String or Bytes. On 2014-07-05, at 13:24, Gerd Stolpmann wrote: > Well, the complexity can be reduced a bit by using phantom types: > > type string = [`String] stringlike > type bytes = [`Bytes] stringlike > > and then just define function-by-function what is permitted: This is almost the same as our first version, which we discarded as too complex and not compatible enough (as you noted, because of unresolved type variables). But it might make a come-back. On 2014-07-08, at 14:24, Gerd Stolpmann wrote: > It will create confusion even with actively maintained code bases. What > could help here is very clear communication when the change will be the > standard behavior, and how the migration will take place. Currently, it > feels like a big experiment - hey, let's users tentatively enable it, > and watch out for problems. OK, we need to be clearer on the "how" (in an nutshell, the default will switch from -unsafe-string to -safe-string at some point in the future when we feel that enough of the existing code has been updated). As for the "when", we can't tell because that depends a lot on how fast the community updates its code. Hopefully no more than three years. Possibly as soon as 4.03.0. > There could also be a section in > the manual explaining the new behavior, and how to convert code. That's a good idea. > Right, that's the good side of it. (Although the danger is quite > theoretical, as most programmers seem to intuitively follow the rule > "don't mutate strings you did not create". I've never seen this kind of > bug in practice.) What about programmers who deliberately trigger the bug (aka "attackers", in a security setting)? It's not just about how unlikely a bug is, but also whether it can be exploited. > For instance, there is one module in OCamlnet where a regexp is directly > run on an I/O buffer (generally, you need to do some primitive parsing > on I/O buffers before you can extract strings, and that's where > stringlike would be nice to have). Without stringlike, I would have to > replace that regexp somehow. If stringlike is polymorphic, you will need a new regexp library that operates on stringlike. We cannot update the current regexp library to use stringlike because that would introduce polymorphism and unresolved type variables, and that might break some of the code that used to run on 1.03... On 2014-07-14, at 19:45, Richard W.M. Jones wrote: > That would imply removing incorrect functions like String.uppercase > and String.lowercase. First, we mark them deprecated. Then we wait a very long time before we actually remove them from (if ever). -- Damien --Apple-Mail=_7D0AC3C1-53BE-4EC3-BD51-6BB6AC62247F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQGcBAEBAgAGBQJTxmQ2AAoJECtup4GFbi7Np7UMAIb1CBg/oJVVg2VZDGC5Wv44 /lAW/2aj3vFXU70PfUrX/IuT7yqppr4jtHGqi3nAm4iz71b/NoKWXH4m2jEi3VjF gHOF2r3qiQgECho71ey4tnWIVDME+CG5smxX5fdB9/0FkNwxEfTDUkOsELjv6Cpp OR4wjPphmlA0cKfCo98SK/HAAwTtC05/EY8/sk4XuOqElnuOP+Y0B/xxYj91rQyV Y8WffMqsZzUV7R7xrZTs7MjrQtscmQbAiq+Bbn2O6/WfnQaHbLLEYKBsdOtjCQt/ TwX75T2vRIp5DVaQxFsa8cni0mG8uZBDW8/humCZ+zMTH5KYVWsR0/AwovI7AfZd 7N28GNedBol6042VIt+WXmD18mouOgzlKNzCdPBCcR3ls+DAXMXzsCpe86k3zpNY TayIZelgg7NcE4G27CbreucTva2AsPHPrNzIymfQPWNx2kFudOwBQ0fa8vz+mjEl Rpo4gRVi//+u3r7U5HFIygrqv63Ouv2UJ1oCH4J9kw== =YsaU -----END PGP SIGNATURE----- --Apple-Mail=_7D0AC3C1-53BE-4EC3-BD51-6BB6AC62247F--