From: Ville-Pertti Keinonen <will@exomi.com>
To: Brian Hurt <brian.hurt@qlogic.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers
Date: Mon, 31 Mar 2003 20:13:24 +0300 [thread overview]
Message-ID: <1487192E-639C-11D7-AF74-000393863F70@exomi.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0303310939470.2225-100000@eagle.ancor.com>
> 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
next prev parent reply other threads:[~2003-03-31 17:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-28 21:19 Brian Hurt
2003-03-28 22:21 ` Yutaka OIWA
2003-03-30 9:51 ` Xavier Leroy
2003-03-31 15:44 ` Brian Hurt
2003-03-31 17:13 ` Ville-Pertti Keinonen [this message]
2003-04-01 8:19 ` Xavier Leroy
2003-04-01 16:09 ` David Brown
2003-04-01 16:45 ` Tim Freeman
2003-04-01 18:59 ` Brian Hurt
2003-04-01 19:16 ` Ville-Pertti Keinonen
2003-04-01 19:23 ` Tim Freeman
2003-04-01 21:00 ` Ville-Pertti Keinonen
2003-04-01 19:56 ` Brian Hurt
2003-04-01 20:45 ` Ville-Pertti Keinonen
2003-04-01 21:03 ` Brian Hurt
2003-04-02 8:55 ` Andreas Rossberg
2003-04-02 9:20 ` Ville-Pertti Keinonen
2003-04-01 18:34 ` Ville-Pertti Keinonen
2003-04-02 11:44 ` Claude Marche
2003-04-02 18:42 Gregory Morrisett
2003-04-02 21:12 ` Ville-Pertti Keinonen
2003-04-02 21:46 ` Lauri Alanko
2003-04-03 17:40 ` Ville-Pertti Keinonen
2003-04-04 16:14 ` Brian Hurt
2003-04-04 17:14 ` Ville-Pertti Keinonen
2003-04-04 17:27 ` Falk Hueffner
2003-04-03 0:52 ` brogoff
2003-04-03 9:29 Fabrice Le Fessant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1487192E-639C-11D7-AF74-000393863F70@exomi.com \
--to=will@exomi.com \
--cc=brian.hurt@qlogic.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox