[rt-devel] Changes for bigint tickets

[Rich Lafferty]

On Wed, Feb 06, 2002 at 09:37:37AM +0100, Bruce Campbell (bruce_campbell at ripe.net) wrote:
> >
> > Still more detail -- It succeeds at 4294967296 (UINT_MAX + 1), but
> > fails at 4294967297 (UINT_MAX + 2). But when it fails at UINT_MAX + 2,
> 
> This is beginning to sound like a perl problem, specifically how perl
> groks numbers. 

$ perl -e '$u = 4294967294; foreach (1..5) { print $u++, ", "}; print "\n"'
4294967294, 4294967295, 4294967296, 4294967297, 4294967298,

I'm not sure. It's a Perl problem inasmuch as the program that's
exhibiting buggy behavior is written in Perl, but I suspect (but don't
yet know) that I'll find the culprit in DBD::mysql, which is XS.

> A peruse of the perlnumber manpage puts the limititations
> on 'a format supported by the C compiler which was used to build perl'.
> You will probably find the above number declared in stdint.h in your
> system (on a handy linux 2.2.x box, its UINT32_MAX )

Well, as I said above, it's UINT_MAX. It's obvious that it's wrapping
around, but it's nonobvious *why* it's wrapping around. I haven't had
a chance to dig in much deeper yet, but I suspect Perl is using an IV
where it should be using an NV. Of course, that should never
happen. :-)

> Perhaps a better solution would be to not mess with the representation of
> the ticket ids in the SQL database (ie, keep as integer). 

I could also declare by fiat that ticket numbers have a new format. :-)

But if I do that, there's still a bug in either DBIx::SearchBuilder,
DBD:mysql, or Perl. Since I've nearly isolated the bug, it'd be silly
not to try and fix it. Dirty hacks are meant to work around something
because it's too hard to fix.

  -Rich

-- 
Rich Lafferty --------------+-----------------------------------------------
 Ottawa, Ontario, Canada    |  Save the Pacific Northwest Tree Octopus!
 http://www.lafferty.ca/    |    http://zapatopi.net/treeoctopus.html
rich at lafferty.ca -----------+-----------------------------------------------