Skip Menu |

This queue is for tickets about the Image-EXIF CPAN distribution.

Report information
The Basics
Id: 45085
Status: rejected
Priority: 0/
Queue: Image-EXIF

People
Owner: Nobody in particular
Requestors: kivinen [...] iki.fi
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Patch to Image-EXIF-1.00.3
Date: Thu, 16 Apr 2009 16:55:07 +0300
To: bug-Image-EXIF [...] rt.cpan.org
From: Tero Kivinen <kivinen [...] iki.fi>
Following patch fixed 2 bugs in the Image-EXIF-1.00.3. The first bug is that the the get_props returns next ep pointer, and if that is used to check whether value should be returned or not, the perl part will never get the last key in the ep list (i.e. when the ep points to last item, it fills in the value, and field, but returns null as return value, as the next ep is null, the c_fetch then didn't return those filled values up as it checked return value). I changed this now so that we still return values in that situation and only check in the next call that if ep is null when c_fetch is called, then we return undef. Another bug is in the exifgps where it uses unsigned n and d, and then tries to multiple n with -1 to make it negative, when this is converted to the doubles, it will get unsigned value, thus returning huge positive value instead of negative. I fixed this by moving the check for negative values after double alt has been calculated and multiplied it with -1 if negative values were needed.
diff -ur Image-EXIF-1.00.3/EXIF.xs Image-EXIF-1.00.3.patched/EXIF.xs --- Image-EXIF-1.00.3/EXIF.xs 2004-08-12 22:32:32.000000000 +0300 +++ Image-EXIF-1.00.3.patched/EXIF.xs 2009-04-16 14:10:29.000000000 +0300 @@ -205,8 +205,8 @@ char field[256] = ""; char value[256] = ""; - int rc = get_props(field, value); - if (rc){ + if (ep) { + int rc = get_props(field, value); EXTEND(sp, 2); PUSHs(sv_2mortal(newSVpv((char*)field, 0))); PUSHs(sv_2mortal(newSVpv((char*)value, 0))); Only in Image-EXIF-1.00.3: Makefile diff -ur Image-EXIF-1.00.3/exifgps.c Image-EXIF-1.00.3.patched/exifgps.c --- Image-EXIF-1.00.3/exifgps.c 2005-01-05 02:28:22.000000000 +0200 +++ Image-EXIF-1.00.3.patched/exifgps.c 2009-04-16 15:11:06.000000000 +0300 @@ -339,17 +339,17 @@ n = exif4byte(t->md.btiff + prop->value, o); d = exif4byte(t->md.btiff + prop->value + 4, o); - /* Look up reference. Non-zero means negative altitude. */ - - tmpprop = findprop(t->props, gpstags, 0x0005); - if (tmpprop && tmpprop->value) - n *= -1; - if (!n || !d) alt = 0.0; else alt = (double)n / (double)d; + /* Look up reference. Non-zero means negative altitude. */ + + tmpprop = findprop(t->props, gpstags, 0x0005); + if (tmpprop && tmpprop->value) + alt *= -1; + /* Should already have a 32-byte buffer from parsetag(). */ snprintf(prop->str, 31, "%.2f m", alt);
-- kivinen@iki.fi
Thanks for your report, Tero. I’ve recently taken over maintainership of Image::EXIF, and I’ve just released Image::EXIF 2.00: https://metacpan.org/release/Image-EXIF This new release contains a fix for the first part of your bug report (though the implementation is now completely different, so your patch isn't included). However, I’m a little hesitant to apply your exifgps.c patch, because that file comes directly from the underlying exiftags software by Eric Johnston: http://johnst.org/sw/exiftags/ Could I suggest you submit that part of your report to him? If he accepts it, I'll do another Image::EXIF release with the updated exiftags. If he doesn't accept it for whatever reason, I’ll reconsider the situation, but I do think it’s valuable to keep the embedded copy of exiftags pristine if possible. Does that make sense?
I'm marking this ticket "rejected", because I haven't heard back from you on the question of resubmitting the bug upstream. If you disagree, please reopen this ticket, or submit a new one. Thanks.