Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Require Western Arabic (ASCII) numerals for max_rows #1

Merged
merged 1 commit into from

2 participants

@patch

Hi Jim,

Previously, any Unicode character with the General_Category property of Decimal_Number was permitted as the value of max_rows. This included Eastern Arabic numerals like ٤٠ and Devanagari numerals like ४० (both represent the Western Arabic 40). However, max_rows was later being used with the numeric equality operator ==, which only understands Western Arabic numerals. I fixed this by replacing \d in the validation regex with [0-9] so that only 0 through 9 are valid and no other of the Decimal_Number characters. Two tests were also added.

Best,
Nick

@patch patch Require Western Arabic numerals for max_rows
Previously, any Unicode character with the General_Category property of
Decimal_Number was permitted as the value of max_rows.  This included Eastern
Arabic numerals like '٤٠' and Devanagari numerals like '४०' (both represent the
Western Arabic '40').  However, max_rows was later being used with the numeric
equality operator (==), which only understands Western Arabic numerals.  This
was fixed by replacing \d in the validation regex with [0-9] so that only '0'
through '9' are valid and no other of the Decimal_Number characters.
e162a87
@jkeenan jkeenan merged commit 4c1b221 into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 15, 2013
  1. @patch

    Require Western Arabic numerals for max_rows

    patch authored
    Previously, any Unicode character with the General_Category property of
    Decimal_Number was permitted as the value of max_rows.  This included Eastern
    Arabic numerals like '٤٠' and Devanagari numerals like '४०' (both represent the
    Western Arabic '40').  However, max_rows was later being used with the numeric
    equality operator (==), which only understands Western Arabic numerals.  This
    was fixed by replacing \d in the validation regex with [0-9] so that only '0'
    through '9' are valid and no other of the Decimal_Number characters.
This page is out of date. Refresh to see the latest.
Showing with 35 additions and 2 deletions.
  1. +1 −1  lib/Text/CSV/Hashify.pm
  2. +34 −1 t/001-new.t
View
2  lib/Text/CSV/Hashify.pm
@@ -257,7 +257,7 @@ sub new {
$data{key} = delete $args->{key};
if (defined($args->{max_rows})) {
- if ($args->{max_rows} !~ m/^\d+$/) {
+ if ($args->{max_rows} !~ m/^[0-9]+$/) {
croak "'max_rows' option, if defined, must be numeric";
}
else {
View
35 t/001-new.t
@@ -2,9 +2,10 @@
# t/001-new.t - check constructor
use strict;
use warnings;
+use utf8;
use Carp;
use Scalar::Util qw( reftype looks_like_number );
-use Test::More tests => 24;
+use Test::More tests => 26;
use lib ('./lib');
use Text::CSV::Hashify;
@@ -113,6 +114,38 @@ my ($obj, $source, $key, $k, $limit);
}
{
+ $source = "./t/data/names.csv";
+ $key = 'id';
+ $limit = '٤٠'; # 40 in Eastern Arabic numerals
+ local $@;
+ eval {
+ $obj = Text::CSV::Hashify->new( {
+ file => $source,
+ key => $key,
+ max_rows => $limit,
+ } );
+ };
+ like($@, qr/^'max_rows' option, if defined, must be numeric/,
+ "'max_rows' option to new() must be in Western Arabic numerals");
+}
+
+{
+ $source = "./t/data/names.csv";
+ $key = 'id';
+ $limit = ''; # Western Arabic 2 followed by Eastern Arabic 7
+ local $@;
+ eval {
+ $obj = Text::CSV::Hashify->new( {
+ file => $source,
+ key => $key,
+ max_rows => $limit,
+ } );
+ };
+ like($@, qr/^'max_rows' option, if defined, must be numeric/,
+ "'max_rows' option to new() must be only in Western Arabic numerals");
+}
+
+{
$source = "./t/data/dupe_field_names.csv";
$key = 'id';
local $@;
Something went wrong with that request. Please try again.