From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA30044; Mon, 31 Mar 2003 19:13:28 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA30474 for ; Mon, 31 Mar 2003 19:13:26 +0200 (MET DST) Received: from mail.exomi.com (mail.exomi.com [217.169.64.72]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h2VHDP507837 for ; Mon, 31 Mar 2003 19:13:26 +0200 (MET DST) Received: from exomi.com (unknown [10.0.5.5]) by mail.exomi.com (Postfix) with ESMTP id 3A8005D03; Mon, 31 Mar 2003 20:13:25 +0300 (EEST) Date: Mon, 31 Mar 2003 20:13:24 +0300 Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ocaml Mailing List To: Brian Hurt From: Ville-Pertti Keinonen In-Reply-To: Message-Id: <1487192E-639C-11D7-AF74-000393863F70@exomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam: no; 0.00; caml-list:01 bug:01 printf:01 redesign:01 pointers:01 runtime:01 allocating:01 -bit:01 ints:01 ocaml:01 garbage:01 int:01 polymorphic:01 optimized:02 native:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > need to do a signed or unsigned int conversion. Or, I suppose, we > could > completely redesign Ocaml to use 32-bit ints and do something else to > differentiate ints from pointers :-). That would only require a redesign of part of the runtime. As far as I can tell, at least for native code, it should only affect the representation of mixed data, garbage collection and use in polymorphic functions, none of which would necessarily be that bad for performance if designed and optimized properly. On the other hand, the efficiency of the current implementation probably has a lot to do with good choices of compromises in allocating the bits of block headers... I wonder how much work it would be to test how efficiently such a change could be done without going all the way...has anyone looked into this? > More pragmatically, I think this behavior should just be documented. > "Broken as designed". Once you know about it, it's annoying not > critical. And maybe %u should be disabled altogether if it can never produce any correct results that differ from %d. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners