On Sat, Sep 18, 2010 at 7:07 PM, Sherm Pendley <sherm.pend...@gmail.com> wrote:
> Found it! What's happening is that, for one- and two-byte return types
> (i.e., char and short), *four* bytes are being stored in a Perl
> variable. Since only one or two bytes were actually returned from the
> method, the other two or three bytes of the value being returned to
> Perl are essentially random.

The question is, why didn't the self-tests catch this? From the NSNumber.t test:

  my $testNumber = NSNumber->numberWithChar(5);
  if (defined $testNumber) {
  } else {

  # It should be able to return a bool, a char, a short, and a long
  if ($testNumber->boolValue()) {
  } else {

  if ($testNumber->charValue() == 5) {
  } else {

I can see why boolValue() would pass when it shouldn't - when this bug
bites, BOOL return values are always nonzero. But the charValue() test
verifies a specific value, not just nonzero. And, there are other
tests in this file, that use various numberWith*() methods to create
NSNumber instances, and *Value() methods to test them. They all pass.

Hmm. None of the *Value() methods take arguments, but isEqual() does.
Maybe the "random" values corrupting the return value from isEqual()
were left over from the argument that was passed in? I tried adding a
couple of tests to check this theory:

  # Compare it with another number
  my $compNumber = NSNumber->numberWithLong(5);
  if ($compNumber->isEqual($testNumber)) {
  } else {

  $compNumber = NSNumber->numberWithLong(50);
  if (!$compNumber->isEqual($testNumber)) {
  } else {

These tests both use isEqual(), and the second one expects it to
return zero. Both tests pass!

I've verified the bug, and verified that it's been fixed in
Subversion. But that was with a GUI app that duplicates the conditions
exactly - using isEqual() to compare $sender to an outlet in an
IBAction method. Obviously those conditions tickle this bug in a way
that the self-tests don't. :-(


Cocoa programming in Perl:

Reply via email to