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?

Because the database query is returning the values as strings, even
though they might be stored in the database as integers.

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

Then you're assigning numeric values, e.g.

@dat[ 3, 4, 5 ] = ( 57, 2045, 2047 );

Try it again with string values assigned and see what happens.

@dat[ 3, 4, 5 ] = ( '57', '2045', '2047' );

While most operators will force their arguments into the numeric or
string context that is appropriate to the operator, the bitwise
operators will change their own context to fit the arguments.

: 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.

Neither print() nor length() will reveal wether the value is stored as a
string or as a number.

I've tested this on 2 separate systems now with the same results, I'd
be interested to see if any of you guys can duplicate it also? Or
tell me where I screwed up, that would be better (and more likely).

The values are strings. Perl defines a bitwise & operator for
strings and hence uses it. Doing the printf causes perl to generate
a numeric version of the value, so then the & operator operates
on the numbers.

The database stuff is all irrelevant (aside from the fact it is returning
strings):

Things like this is why the knowledgable people here always argue against
posters who quote variables for no reason (replace the '("$x", "$y", "$z")'
in that code with '($z, $y, $z)' and the bahaviour will change).

> While most operators will force their arguments into the numeric or
> string context that is appropriate to the operator, the bitwise
> operators will change their own context to fit the arguments.

Ahh, you know I don't think I knew that. Funny this hasn't affected
me earlier, though I guess I don't do a lot of bit operations on data
from databases.

I guess it was just drilled into my head that perl doesn't have data
types, so the thought never crossed my mind that it would care that
the data is actually a string and not an integer. And it doesn't --
except for bit operations.

Well, thanks, that saved me a lot of fruitless debugging. Obviously
my follow-up I just made can be disregarded, though, at least the code
actually 'works' in that one (or doesn't, depending on how you look at
it).

Thanks for the feedback. I think we've got it solved. I really should
just start reading these groups instead of just showing up when I have
problems, I may learn something.
>> my @dat = &GetHostStatus( $_ );
>
> Why are you using the & there?

Ok, I'll admit it, I'm an armchair perl programmer. I'm a long-time C
programmer professionally, but I use perl quite a bit for web scripting and
what not. So, with the disclaimer out of the way, may I ask, "What did I
mess up this time?" I'm assuming my implementation is not ideal, but
here's why I do/did it. 1) It's how I learned -- subroutines begin with an
&. 2) It helps me visually identify subroutines (ok, that's kind of weak).
I know I've seen it left off, but I never explored the how and why. So,
tell me.. why?

On Tue, 21 Oct 2003 04:39:53 GMT, dohnut <> wrote:
> Sam,
>
> Thanks for the feedback. I think we've got it solved. I really should
> just start reading these groups instead of just showing up when I have
> problems, I may learn something.
>
>>> my @dat = &GetHostStatus( $_ );
>>
>> Why are you using the & there?
>
> Ok, I'll admit it, I'm an armchair perl programmer. I'm a long-time C
> programmer professionally, but I use perl quite a bit for web scripting and
> what not. So, with the disclaimer out of the way, may I ask, "What did I
> mess up this time?" I'm assuming my implementation is not ideal, but
> here's why I do/did it. 1) It's how I learned -- subroutines begin with an
> &. 2) It helps me visually identify subroutines (ok, that's kind of weak).
> I know I've seen it left off, but I never explored the how and why. So,
> tell me.. why?

See the documentation in 'perldoc perlsub'.

or the FAQ:

"What's the difference between calling a function as &foo
and foo()?"

Findable with:

'perldoc -q "&"'

Which also find the answer to your previous question, which I didn't
realise was a FAQ. If I had I would have provided a pointer in my
original reply, mea culpa...

In a nutshell, it disables prototypes. You didn't have any
prototypes so that doesn't matter so much, but turning off a
mechanism for finding errors for no real benefit is silly, in the
general case.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!