223711 - collectstats.pl: Use of uninitialized value in pattern match (m//) at Bugzilla/Util.pm line 50

Status: RESOLVED DUPLICATE of bug 210735

(Bugzilla :: Reporting/Charting, defect)

Description

[Jason Pyeron]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: 

hmmm, going to check into this

I was working on Bug 183753 

Reproducible: Always

Steps to Reproduce:

Comment 1

[Jason Pyeron]

Attachment: patch-bugzilla-tip-200310260444.diff

why are there so many silly things in here...

Comment 2

[chaduv]

I can confirm that this occurs. However... instead of just hiding the problem, 
should callers of trick_taint be required to pass in a real argument?

Comment 3

[Jason Pyeron]

re comment 2: yes, but that is another issue (Bug 223836).

I am just triaging bz right now.

I also just found out when my patch is not applied checkstats fails to run as 
expected a second time, hence change to MAJOR issue

Comment 4

[Bradley Baetz (:bbaetz)]

Please don't do this. We need to fix the callers instead.

Comment 5

[Jason Pyeron]

Attachment: patch-bugzilla-tip-200310271628.diff

I agree with you and that is why there is the other bug,

but what is wrong with:

$var=taintedMethod();
# this method returns undef if case X exists otherwise value ...
...

detaint_xxx($var);

...

if (!defined($var)) ...

Comment 6

[Vlad Dascalu]

Comment on attachment 134274 [details] [diff] [review]
 patch-bugzilla-tip-200310271628.diff

We actually use CVS instead of comments for recording who created the patch and
which bug number was used for tracking it :)

Also the identation in the patch doesn't respect  the
http://www.bugzilla.org/developerguide.html standard.

Comment 7

[Jason Pyeron]

I am sorry if my formatting does not conform, but I am unable to read or write 
in the 


if (...) {

}


this is a deal breaker (I have a reading/vision problem, it takes a long time 
to get used to other ways)


I would be more than happy to file a bug to pretty up my code after each patch 
submision?

Comment 8

[Jason Pyeron]

it is the same reason why I usually dont wrap lines.

Comment 9

[Jason Pyeron]

Attachment: patch-bugzilla-tip-200310311914.diff

sorry, the -w was triming spaces out...

I use the -w(windoz) by habbit since my developers/I deal with CRLF issues 24/7

Comment 10

[Zach Lipton [:zach]]

Checking in code that doesn't comply with the style guidelines and filing a bug
to fix it later is a bad idea. Instead, why don't you write the patch using any
method that works for you, and then clean it up before you diff? 

The bigger issue is that this needs to be fixed in the callers of trick_taint().
Considering the purpose of the function, there is no reason it should be
handling null input. 

Comment 11

[Gervase Markham [:gerv]]

In addition, the -w parameter to diff is "whitespace", not "windows", and should
generally not be used for patches submitted for checking in.

Gerv

Comment 12

[Jason Pyeron]

LOL: yes I know -w is not for windows, 

I use an editor from 1992, it sometimes put bad CRLF artifacts in the files.


its only downside is if I indent existing code.

I.E.:
code
[blank line]
code
[blank line]
code
[blank line]
code
[blank line]

Comment 13

[Gervase Markham [:gerv]]

I believe this is bug 210735 (at least, the symptoms match), which I've just
checked the patch in for.

Gerv

*** This bug has been marked as a duplicate of 210735 ***

Comment 14

[Vlad Dascalu]

Comment on attachment 134589 [details] [diff] [review]
patch-bugzilla-tip-200310311914.diff

Canceling review requests on a closed bug.