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 D209F7EE49 for ; Thu, 19 Sep 2013 11:47:18 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0BAPjGOlLU4w8Em2dsb2JhbABbv3+FP4EiFg4BAQEBAQYLCwkUKIIlAQEFOk8LGAklDwUoNIdwARavTR+KGo9uFoMIgQADl3uGHo5+ X-IPAS-Result: Aq0BAPjGOlLU4w8Em2dsb2JhbABbv3+FP4EiFg4BAQEBAQYLCwkUKIIlAQEFOk8LGAklDwUoNIdwARavTR+KGo9uFoMIgQADl3uGHo5+ X-IronPort-AV: E=Sophos;i="4.90,936,1371074400"; d="scan'208";a="33501528" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 19 Sep 2013 11:47:17 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LfidG-1VfkYZ3Xsw-00pIlr for ; Thu, 19 Sep 2013 11:47:17 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1VMapR-0006so-83 for caml-list@inria.fr; Thu, 19 Sep 2013 11:47:17 +0200 Date: Thu, 19 Sep 2013 11:47:17 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20130919094717.GD25801@frosties> References: <20130919061838.17829.qmail@www1.g3.pair.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130919061838.17829.qmail@www1.g3.pair.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:iQSkGGZTy0EZlptwT4chGCdeh9DWPffvlAGRa5JbcYKIf1i3tC7 8w0IzK3wKDN3ijxoaItoTMMyfOF9xUiANOhi98xmDd2bH8bfvi4FX6B2v7MfOxA0hrWs8ri vYQNLotz0VfFEINgvT74DURRpGoPozBvQ3DiPuBvv2/3yht5Vy4d477dk7Tb2ZUiT1P1mf0 yTTJHMk3V1L+HzPND5npw== Subject: Re: [Caml-list] Expanding the Float Array tag On Thu, Sep 19, 2013 at 06:18:38AM -0000, oleg@okmij.org wrote: > > I am curious about the focus on generalizing double_tag or > double_array_tag when there is already a seemingly good candidate for > tagging values that should not be scanned. I mean the > string_tag. Please search the OCaml code for string_tag and > String_tag. You see it is mentioned in generic routines like > generic comparison compare.c -- which uses memcpy anyway, thus > treating the string just like a sequence of bytes. Other generic > functions like hash are similar. The only other non-trivial use of > string_tag is in printexc and the likes. Those cases are indeed > problematic. Other than them, string_tag can denote arbitrary opaque > byte array and noone will notice. Incidentally, if by string we mean > UTF-8 or UTF-16 string, it is essentially a sequence of bytes anyway. Strings are special in that they have a length in bytes. The length in words is taken from the header, multiplied by the word size and the delta to the real string length is stored in the last byte of the block. Reusing the string tag would confuse code that relies on this, like marshaling. MfG Goswin