EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #02013

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: Change in behaviour in Perl 5.16, and EPrints

Thanks for this, Ian, we'll look into it -> https://github.com/eprints/eprints/issues/88

Seb

On 13/06/13 14:39, Ian Stuart wrote:
I don't know if this has surfaced as an issue yet, however Perl has 
changed the behaviour of utf8::decode() as of 5.16
(see https://rt.perl.org/rt3/Public/Bug/Display.html?id=115196)

Prior to 5.16, if you decoded an undef value, you got undef back
 From 5.16 onwards, decoding a value always returns a string, even if 
its a null string (defined, but zero length: "")


This was a major problem in EPrints::Repository::param for me, as it is 
used in EPrints::Plugin::Export::param:

EPrints::Plugin::Export
sub param
{
	my( $self, $paramid ) = @_;

	# Allow args to override mimetype
	if( $self->{session}->get_online
	 && $paramid eq "mimetype"
	 && defined $self->{session}->param( "mimetype" ) )
	{
## flawed as $self->{session}->param( "mimetype" ) always
## returns defined

		return $self->{session}->param( "mimetype" );
	}
	return $self->SUPER::param( $paramid );
}


In 3.2.9, there are not that many files that use itf8::decode

 From my review of them, the following already address the problem:
perl_lib/EPrints/XML.pm
perl_lib/EPrints/XHTML.pm

The following need to be reviewed, as they may now have unforseen 
side-effects:
perl_lib/EPrints/Repository.pm
perl_lib/EPrints/Update/Views.pm
perl_lib/EPrints/MetaField/Id.pm

The following I'm not sure about, but I think are basically safe:
perl_lib/URI/OpenURL.pm
perl_lib/EPrints/Index/Tokenizer.pm
perl_lib/EPrints/XML/LibXML.pm
perl_lib/EPrints/XML/GDOME.pm
perl_lib/EPrints/XML/DOM.pm


... this may have been addressed in 3.3.<later>