469,356 Members | 1,965 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,356 developers. It's quick & easy.

Odd Perl bitwise-AND & MySQL problem?

Here's one for some bored problem solver :)

I ran across this earlier today and fixed it, but don't exactly know
why. (that usually only happens in C :)

I'm using Perl version 5.8.0 btw.

Ok, let's start here: I end up with an array that comes from a
fetchrow_array() call to MySQL. I return the array to a function.

Ok, then the function does this (roughly):

sub func()
my @dat = shift;

my $val = $dat[3] & $dat[4] & $dat[5] & 0x7fff;

print $val;

In the MySQL database, element 0 = int, 1 = varchar(32), 2 =
varchar(255), 3 = int, 4 = int, 5 = int, 6 = int, etc..

Ok, so I call the function. Let's assume $dat[3] = 57 (0x39), $dat[4]
= 2045 (0x7fd), $dat[5] = 2047 (0x7ff).

Guess what I get for output? --> "00" (I should get 57 (0x39) btw)

Not just a zero "0" but _2_ zeros. So, clearly it thinks something
stringy is there. But why? I guess that is my question.

Now, if I populate @dat myself (i.e. don't get the values from MySQL
calls) it works fine.

To my knowledge only numbers are in the 3 variables and I've tested
this. If I print the values individually, they print correctly. I
also do a 'length' on them and I get 2, 4, and 4 respectively -- which
is correct.

How did I fix it?

my $val = int($dat[3]) & int($dat[4]) & int($dat[5]) & 0x7fff;

I added int()s around each value. So apparently Perl thought there
was something before the numbers in the variables?? Nothing should be
there but numbers, the values come from table elements that are ints
and are read right into a Perl array. Aside from a bug, I can't see
how this could get corrupted or how I could be missing something.

I've done quite a bit of MySQL/Perl programming and I've never had
this happen before, in fact, this specific problem doesn't happen all
the time even in this code. Only with when returning data from
specific rows (in my case), though it is consistent and reproducable
-- it's not flaky. I can note that $dat[2] (which comes from a
varchar(255)) contains some text and some "/r/n" characters. The ones
that don't fail don't contain "/r/n" characters in $dat[2]. I don't
know if this is related, I only have 3 rows of data (at the moment)
and 1 causes the problem.

I'm thinking this is a problem in the Perl MySQL DBI module? I
realize I can do more troubleshooting to narrow it down a bit better
and I probably will tonight, but just wanted to get it out there and
see what people thought. Maybe this has been seen before?
Jul 19 '05 #1
0 2027

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

34 posts views Thread by Christopher Benson-Manica | last post: by
12 posts views Thread by sandy_pt_in | last post: by
8 posts views Thread by Mantorok Redgormor | last post: by
8 posts views Thread by Paul E Collins | last post: by
2 posts views Thread by Aamir Mahmood | last post: by
2 posts views Thread by Random | last post: by
6 posts views Thread by Fredrik Melin | last post: by
6 posts views Thread by Ramtin Kazemi | last post: by
16 posts views Thread by Santhosh | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.