Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Convert-ASN1 CPAN distribution.

Report information
The Basics
Id: 12424
Status: resolved
Priority: 0/
Queue: Convert-ASN1
People
Owner: Nobody in particular
Requestors: salvejn+cpanbug [...] met.no
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 0.17
Fixed in: (no value)

History Show all quoted text
  Wed Apr 27 06:35:04 2005 Guest - Ticket created
Subject: Convert::ASN1::_encode complains of uninitialized value
When running the SPOPS [1] module tests, there are a couple of warnings that pop up each time. Keeping in mind the concept of "fix broken windows" [2], would it be sensible to find a way to silence these warnings, without silencing other (useful) warnings? I'm thinking that the concept of testing for undef values may be useful enough (at least in this case) to warrant a "fix" in this module... The basic warning looks like this: Use of uninitialized value in length at /usr/share/perl5/Convert/ASN1/_encode.pm line 144, <DATA> line 283. Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Convert/ASN1/_encode.pm line 145, <DATA> line 283. Use of uninitialized value in length at /usr/share/perl5/Convert/ASN1/_encode.pm line 144, <DATA> line 283. Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Convert/ASN1/_encode.pm line 145, <DATA> line 283. A more detailed output can be found attached to corresponding SPOPS bug report [1]. [1] http://jira.openinteract.org/browse/SP-15 [2] http://c2.com/cgi/wiki?FixBrokenWindows
  Wed Apr 27 10:53:50 2005 gbarr [...] pobox.com - Correspondence added
Date: Wed, 27 Apr 2005 09:34:58 -0500 (CDT)
Subject: Re: [cpan #12424] Convert::ASN1::_encode complains of uninitialized value
From: "Graham Barr" <gbarr [...] pobox.com>
To: bug-Convert-ASN1 [...] rt.cpan.org
RT-Send-Cc:
On Wed, April 27, 2005 5:35 am, Guest via RT said: Show quoted text
> When running the SPOPS [1] module tests, there are a couple of warnings > that pop up each time. > > Keeping in mind the concept of "fix broken windows" [2], would it be > sensible to find a way to silence these warnings, without silencing other > (useful) warnings?
If there is to be any change then the library should croak. undef is not a valid input here. Can you provide a small testcase that reproduces this as I would like to track how undef is getting that far into the code. Graham.
  Wed Apr 27 11:19:40 2005 gbarr [...] pobox.com - Correspondence added
Date: Wed, 27 Apr 2005 10:07:24 -0500 (CDT)
Subject: Re: [cpan #12424] Convert::ASN1::_encode complains of uninitialized value
From: "Graham Barr" <gbarr [...] pobox.com>
To: bug-Convert-ASN1 [...] rt.cpan.org
RT-Send-Cc:
On Wed, April 27, 2005 9:53 am, Graham Barr via RT said: Show quoted text
> > This message about Convert-ASN1 was sent to you by gbarr@pobox.com > <gbarr@pobox.com> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=12424 > > > On Wed, April 27, 2005 5:35 am, Guest via RT said:
>> When running the SPOPS [1] module tests, there are a couple of warnings >> that pop up each time. >> >> Keeping in mind the concept of "fix broken windows" [2], would it be >> sensible to find a way to silence these warnings, without silencing >> other >> (useful) warnings?
> > If there is to be any change then the library should croak. undef is > not a valid input here. > > Can you provide a small testcase that reproduces this as I would like > to track how undef is getting that far into the code.
Having looked a little deeper, I think the source of the issue is actually this code in SPOPS::LDAP # Trick LDAP to creating object with multivalue property that # has no values if ( ref $insert_data{ $attr } eq 'ARRAY' and scalar @{ $insert_data{ $attr } } == 0 ) { $insert_data{ $attr } = undef; } Which causes Net::LDAP to pass [ undef ] into Convert::ASN1 which produces the warning. So Net::LDAP should probably catch this and issue a warning. But SPOPS::LDAP should send [] not undef for this particular case Graham.
  Fri Jun 08 19:07:11 2012 GBARR [...] CPAN.ORG - Status changed from 'new' to 'resolved'