unsinged integer

ups (typo + copy past error)

It's not my day today!

I like to create an RFC to add an unsinged integer type

+1 for not turning the iron up too high when doing your maths!

[https://en.wiktionary.org/wiki/singe]

Sorry, it's a common typo, but it made me chuckle that you used it in
both the subject and first sentence.

More seriously, UnsignedInt might go nicely alongside Andrea's BigInts...

More seriously, UnsignedInt might go nicely alongside Andrea's BigInts…

Bigints kinda remove the need for unsigned ints as you’d be able to use big signed integers of any size. I also really don’t want unsigned int because it makes integer semantics more confusing and you’re splitting integers into two different kinds, unlike bigints which are an implementation detail (there is still just one “integer” type) for the most part.

I really, really don’t think this proposal is a good idea.

Andrea Faulds
http://ajf.me/

I mean a new scalar type here

On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz php@marc-bennewitz.de
wrote:

Hi all,

I like to create an RFC to add an unsigned integer type for the
following purposes:

• higher max value
  • DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
    in PHP
• better support pack/unpack unsigned integers from/to PHP using the
  un/pack functions
• simplified right shift of unsigned integers because PHP "safes" the
  sign bit on signed integers which leads to bugs or overcomplicated code
  if you need that bit for others than a sign
• if a parameter type-hint or similar functionality will be implemented
  this type will be very useful, too. Else it will be also useful to make
  sure you have no negative integer by simply converting to it.

What do you think?
(Does it worth the expense for a RFC?)

Could you please further clarify what you mean by "type" here? If you mean
an actual new type (like integers currently are), then I highly doubt this
is feasible (implementationally).

If you mean something like an UnsignedInt class with overloaded operators,
that should be easy to implement. Not sure if we want it in core though.

Nikita

Hi Marc,

This is an unusual follow-up from me.

Particularly on 32-bit systems, it would be useful to have a ‘u’ zend_parse_parameters specifier for an unsigned integer. Unfortunately, again, I don’t think native unsigned integers (IS_ULONG) will get into PHP. But it looks like the bigint RFC probably will, and here’s the opportunity.

With the bigint RFC, we could add a ‘u’ specifier. You’d get a native ulong (zpp would convert from long or bigint), and could easily produce a long/bigint from your ulong if you need to return one (add RETURN_ULONG which implicitly converts?).

Now, it’s not as fast as a native IS_ULONG type would be, but we could still do things like properly support file sizes in the 2GB-4GB range on 32-bit, at least. :)

What do you think?

It looks to me like yet another can of worms (how do you deal with
conversions, mixed operations, etc. it adds a lot of special cases)
with little benefits. 32bit environments are dying species. There are
ways to support LFS without that as well (while I doubt the effort is
worth it). So if I'd to choose whether PHP should support unsigned
integer, my gut feeling right now is no, it should not.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org