improper definition of $::components in globals.pl

RESOLVED FIXED in Bugzilla 2.14

Status

()

RESOLVED FIXED
17 years ago
6 years ago

People

(Reporter: avm3, Assigned: justdave)

Tracking

unspecified
Bugzilla 2.14
x86
Windows 2000

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
The datastructure for $::components looks like this

  hash {
     scalar "product" => array []
  }

however, on line 504, if the product is not defined
in the component list, the value for that product
gets set to a scalar rather than an anonymous array.

This bug bit me when I was upgrading from 2.10 to
2.12: I had not component defined for a certain
product.

Here is the patch that solved it (the patch is
made agains the current revision [1.95]):

cvs -z9 -q diff globals.pl (in directory D:\dev\moz\mozilla\webtools\bugzilla\)
Index: globals.pl
===================================================================
RCS file: /cvsroot/mozilla/webtools/bugzilla/globals.pl,v
retrieving revision 1.95
diff -r1.95 globals.pl
504c504
<             $::components{$i} = "";
---
>             $::components{$i} = [];
Target Milestone: --- → Bugzilla 2.14
remember all that "Can't use STRING("") as an ARRAY reference" crap?

This was the real reason for it.  The patch we checked in before only covered it 
up.  Fixing this will break the original coverup patch, btw (at least I think it 
will).  The coverup was bug 40987.
(Reporter)

Comment 2

17 years ago
Dave, bug 40987 was trying to address the problem of

  Can't use string ("") as an ARRAY ref while "strict refs" in use 

But it was a hack.  To define that there were no components for a
product, the value of a product was set to "" (a scalar), i.e.:

  $::components{$product} = ""

And similarly, to test if there were no components, a test was done
to see if the value associated with a product was '0', that is:

  if (0 == $::components{product}) 

This all worked very fine and dandy in rev. 1.36.  But in revision
1.95 I noticed two things:

  1. globals.pl *assumes* a consistent data structure for $::components
  2. the value associated with a produt is *always* an array reference

So now, when the $::components is being generated, if there is a
product without components that is being added, it is generated as such:

  $::components{$p} = [];

This is seen at lines 296, and 424.  And to verify that something is
not already defined for specific product, this test is done:

  if (! defined $::components{$prod})

These works very well, except that there is one line (504) which reads:

  $::components{$p} = "";

My guess is that this is legacy code that someone forgot to change.
It violates consistency [1] stated above.  Simply doing the patch
that I provided, clears up this problem.  Now it is entirely possible
that code somewhere is still checking for values of "" (or '0' in
numeric context).  I cannot guarantee that it's not happenning since
I have not reviewed all the code.  But it looks to me like it was just
an oversight (and perhaps that section of code never really got used
when upgrading on bugzilla databases that are "correct", i.e. products
have at least one component).

OK, the attachment patches the original coverup patch to handle the data type 
consistently, and also fixes the original definition as was noted here.  I've 
tested this on my local install, and it seems to work well.
Keywords: patch, review

Comment 5

17 years ago
Looks good to me.

r=jake
Assignee: tara → justdave
checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.