Matthew,
Yes, all of these problems can be solved - I am well aware of that. I am
also painfully aware of how much time it can take to solve them reliably.
I just would like to see a solution rather than a bunch of work-arounds -
not for my own sake, my problem is solved, but for the sake of every poor
fool who's going to fall into these traps.
That's all.
On Fri, Aug 30, 2013 at 2:44 PM, Matthew Leverton <lever...@gmail.com>wrote:
> On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz <ras...@mindplay.dk>
> wrote:
> > array(2) {
> > [2130706433]=>
> > string(3) "foo"
> > ["4294967040"]=>
> > string(3) "bar"
> > }
> >
> > The keys are now two different types (string vs int) on 32-bit platforms,
> > which leads to problems with strict comparison.
> >
> Prefix your keys with any alpha char to enforce a consistent string type.
>
> > Another issue is persistence - if you save these to unsigned integer
> columns
> > in database, and your data access layer converts them back to integers on
> > load, the values are going to change again depending on what platform
> you're
> > on.
> >
> I've never had that issue with any database layer I've ever worked
> with. Not saying that no such db layer exists, but if you use PHP with
> big integers, then you should treat them as strings in and out. If you
> want to do math on them, then you have to use one of the bigint
> libraries. If you want them for display purposes, keep them as
> strings.
>
> > To quote the specific case where I encountered this, I have an audit
> trail
> > system that logs a lot of user activity - as an optimization, I hash and
> > store certain keys using crc32() numeric values, since storing a 32-bit
> > number is much cheaper (in terms of storage) than storing strings, as
> well
> > as giving much faster queries.
> >
> Again, you should be able to store them from a string int to database
> int without any issues. If so, I'd suggest fixing this at the database
> access layer.
>
> > Why would you consider a consistent function "crippled"?
> >
> It's crippled in the sense that it punishes people who are using
> modern hardware from intelligently processing the return value. I have
> a 64-bit system, and it returns a negative number for a 32-bit CRC?
>
> > Look at the sheer number of comments on the crc32 manual page and tell
> me if
> > you still think this works well for anybody... many of the comments
> > (including mine!) aren't even correct and don't lead to predictable
> > results...
> >
> A lot of PHP functions have tons of user error from people who haven't
> bothered to read the existing manual entry or other comments.
>
> > This should be easy but it is extremely hard.
> >
> There should never be the expectation that things "just work" without
> having to understand the core features and limitations of the
> language. To me, the examples you are giving are just two cases of the
> larger problem of 32 vs 64 bit. There really is no getting around the
> fact that scripts with integers behave differently depending on the
> system.
>
> So while I don't mean to sound dismissive of your complaints (because
> they are valid), I just don't see how two bandaids over specific
> instances of a larger problem do much good. Although, to be pragmatic,
> I offered what I feel is a better solution than your extra functions.
>
> --
> Matthew Leverton
>
