Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007280OCamlstandard librarypublic2016-06-27 23:072017-06-14 18:39
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007280: Add basic unsigned int32 and int64 support
DescriptionIt would be nice to have the following functions available in the stdlib as they are not easy to add externally:



Or possibly their equivalents in Int(32|64).Unsigned modules.
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0004908acknowledged Requesting unsigned types 

-  Notes
gasche (developer)
2016-06-28 00:20

To understand the issue better I looked at how `int32` is represented now in the compiler and runtime. It is a custom type, which means that polymorphic comparison/serialization function lookup the type-specific implementation. The compiler knows about a family of %int32_foo primitives for these types and replaces them by direct call to the underlying functions.

I think if we wanted good support for unsigned integers in the language adding abstract uint{32,64} types would be a good solution -- implemented as custom types with their own comparison/serialization, and their own compiler primitives.
hcarty (reporter)
2016-06-28 00:48

That's fine too. There was a mailing list post that I can't find now which lead me to believe that separate unsigned types/modules wouldn't be welcome. If we can have fully separate types then that should make them simpler for users to find and understand too.
frisch (developer)
2016-06-29 10:04

It seems really bad to mix signed and unsigned ints of the same size in a single type. I'm not aware of any high-level language that does that.

So unsigned ints would be new built-in types; they need to be built-in because the optimizer needs to know about them, at least to support local unboxing and constant folding. We'd also need to provide operations such as "/" and "mod", and I guess this would impact the runtime system (primitives) and/or the various backends. So this is really not a "pure stdlib" proposal.

How common is the need for unboxed int types? Can you provide some typical usage scenarios?

> as they are not easy to add externally:

Can you elaborate on that part? I guess that in both cases (stdlib or external), there would be a need for new C primitives.
hcarty (reporter)
2016-06-29 13:17

Here is the post:, [^] and a related Stack Overflow response: [^] - those are why the initial request is/was for additional operations on the existing types.

If separate types and operations are an option then, again, that seems like a better solution.

As far as external libraries, the biggest issues are optimization (can a user-defined integer type ever be as efficient as one that is built in?) and bigarray support. I've run into both, primarily when working with serialization formats which assume the presence of unsigned integers.
paurkedal (reporter)
2016-06-29 20:53

I think int63 and uint63 types would also be useful, considering that they are unboxed on 64 bit targets, while int on 32 bit targets may be too small for some applications.
yallop (developer)
2017-06-14 18:39

There's a pull request with an implementation of unsigned 32-bit and 64-bit integers here: [^]

- Issue History
Date Modified Username Field Change
2016-06-27 23:07 hcarty New Issue
2016-06-28 00:20 gasche Note Added: 0016014
2016-06-28 00:48 hcarty Note Added: 0016015
2016-06-29 10:04 frisch Note Added: 0016018
2016-06-29 13:17 hcarty Note Added: 0016020
2016-06-29 20:53 paurkedal Note Added: 0016021
2017-01-03 09:11 yallop Relationship added has duplicate 0004908
2017-02-23 16:43 doligez Category OCaml standard library => standard library
2017-04-14 16:38 doligez Status new => acknowledged
2017-06-14 18:39 yallop Note Added: 0017880

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker