libexif-devel — This is the place where your questions about libexif will be answered.

[Libexif-devel] New Slovak PO file for 'libexif' (version 0.6.16)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Slovak team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/sk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] using libexif for reading from jpeg file, ideally for writing to jpeg file as well

[Guillaume C. <gco...@gm...>]

Hi,

I've recently migrated the use of ImageMagick's identify to libexif
for reading orientation and original date-time from jpeg files. I must
confess the speed improvement is dramatic[1].

Now, I'd like to overwrite or add the orientation of jpeg files. I've
read the source of commandline "exif", my problem is the needed stuff
from libjpeg/: ideally, I really would like not to embed this  code in
my program. I was wondering why it is not provided by libexif, and
incidentally I learnt from libexif's ChangeLog that libjpeg/ was
previously part of it. So there must be some reasons? Any advice from
this point on?

[1] http://zarb.org/~gc/html/doc-misc.html#2007-06-16

-- 
Guillaume Cottenceau - http://zarb.org/~gc/

Re: [Libexif-devel] crashes using exif/cygwin

[<th...@ka...>]

> I often get crashes using exif/cygwin. Is anyone interested in a sample 
> image? Shall I file a bug?

sorry for the noise, not reproducible with latest version :-/

Thomas

[Libexif-devel] crashes using exif/cygwin

[<th...@ka...>]

Hello list,

I often get crashes using exif/cygwin. Is anyone interested in a sample 
image? Shall I file a bug?

Best regards,
Thomas

[Libexif-devel] New Slovak PO file for 'libexif' (version 0.6.16)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Slovak team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/sk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [Libexif-devel] libexif/libexif exif-data.c,1.96,1.97

[Hans U. N. <hu...@n-...>]

Jan Patera wrote:
>> file: /cvsroot/libexif/libexif/libexif/exif-data.c,v
>> -	if ((ifd < 0) || (ifd >=3D EXIF_IFD_COUNT))
>> -		return;
>> +	/* check for valid ExifIfd enum range
>> +	 * if ((((int)ifd) < 0) || (ifd >=3D EXIF_IFD_COUNT))
>> +	 * return;
>> +	*/
>> +	switch (ifd) {
>> +	case EXIF_IFD_0:
>> +	case EXIF_IFD_1:
>> +	case EXIF_IFD_EXIF:
>> +	case EXIF_IFD_GPS:
>> +	case EXIF_IFD_INTEROPERABILITY:
>> +	case EXIF_IFD_COUNT:
>> +	  break;
>=20
> Hans,
>=20
> EXIF_IFD_COUNT is not a valid IFD ID - it is the counter of the IDs.

Argh. :-)

Fixing check, commenting EXIF_IFD_COUNT.

Re: [Libexif-devel] libexif/libexif exif-entry.c,1.104,1.105

[Hans U. N. <hu...@n-...>]

Jan Patera wrote:
>> make sure the returned string is zero terminated
>=20
>> +	val[maxlen-1] =3D '\0'; /* make sure the returned string is zero
>> terminated */
>=20
> Hans, this is not needed. Actually it is contraproductive - it may
> cut the string by one 1 byte:
>=20
> All the get functions start with this:
>=20
> 	memset (val, 0, maxlen);
> 	maxlen--;
>=20
> To ease coding.

Argh. I had not seen that. Reverting patch, adding comment.

Thanks for paying attention.

Re: [Libexif-devel] libexif/libexif exif-data.c,1.96,1.97

[Jan P. <pa...@pi...>]

> file: /cvsroot/libexif/libexif/libexif/exif-data.c,v
> -	if ((ifd < 0) || (ifd >= EXIF_IFD_COUNT))
> -		return;
> +	/* check for valid ExifIfd enum range
> +	 * if ((((int)ifd) < 0) || (ifd >= EXIF_IFD_COUNT))
> +	 * return;
> +	*/
> +	switch (ifd) {
> +	case EXIF_IFD_0:
> +	case EXIF_IFD_1:
> +	case EXIF_IFD_EXIF:
> +	case EXIF_IFD_GPS:
> +	case EXIF_IFD_INTEROPERABILITY:
> +	case EXIF_IFD_COUNT:
> +	  break;

Hans,

EXIF_IFD_COUNT is not a valid IFD ID - it is the counter of the IDs.

 -- Jan

Re: [Libexif-devel] libexif/libexif exif-entry.c,1.104,1.105

[Jan P. <pa...@pi...>]

> make sure the returned string is zero terminated

> +	val[maxlen-1] = '\0'; /* make sure the returned string is zero
> terminated */

Hans, this is not needed. Actually it is contraproductive - it may
cut the string by one 1 byte:

All the get functions start with this:

	memset (val, 0, maxlen);
	maxlen--;

To ease coding.

  -- Jan


> Index: exif-entry.c
> =================================================================== RCS
> file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
> retrieving revision 1.104
> retrieving revision 1.105
> diff -u -p -d -r1.104 -r1.105
> --- exif-entry.c	26 Jun 2007 02:35:35 -0000	1.104
> +++ exif-entry.c	26 Jun 2007 02:36:46 -0000	1.105
> @@ -1095,6 +1095,7 @@ exif_entry_get_value (ExifEntry *e, char
>  		}
>  	}
>
> +	val[maxlen-1] = '\0'; /* make sure the returned string is zero
> terminated */
>  	return val;
>  }

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.101, 1.102

[Hubert F. <hfi...@te...>]

Jan Patera wrote:
> 4) However, I do know that 4=sizeof(int)<sizeof(long)=8 on 64bit
>   Windows, but 8=sizeof(int)=sizeof(long)=8 on 64bit Mac OS.
>   We have not declared 64bit support yet, but we will have to do so
>   very soon.

On Linux x86_64
sizeof(int) == 4
sizeof(long) == 8
sizeof(void*) == 8

On Linux x86 and ppc
sizeof(int) == 4
sizeof(long) == 4
sizeof(void*) == 4


> 5) sizeof(int) indeed is not the same as sizeof(void*).

Never should me assumed.

> 6) Q: do we still have to bother with 16bit int?

Yes it can be useful.

#include <stdint.h> and be done with one. There is one retarded platform
that have to work around it. For the rest we have configure.


Hub

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.101, 1.102

[Hans U. N. <gp...@n-...>]

Jan Patera wrote:

> I see we need several audits. One of them is for the types and formatting
> sequences used.

I wholeheartedly agree.

> 1) libexif doesn't use size_t and ssize_t anywhere, except of exif-mem.c
>   where the arguments to calloc and realloc are typecast to size_t

size_t and ssize_t should be for memory area sizes, and nothing else, right?

> 2) size members in all our structures are always unsigned int. Therefore

unsigned int is definitely wrong. However, changing that to unsigned
long is going to break ABI compatibility, so we need to plan ahead a
little before just breaking the ABI with each release every two weeks.

One (mostly) API compatible ABI break for that stuff is OK imho.

>  I agree rather %u should be used, also to catch bugs and problems,
>  like the recent iDefense problem and the Michele's report.

I doubt that using %u in format strings is going to help us find many
integer type bugs.

>  Some functions use ExifLong which is supposed to be 32bit.

EXIF defines an (EXIF) long to be 32bit.

> 3) Again, I did unification - both %li and %i were used on different places
>  in the same situation.

Well... we have no format strings available (unless we want to use
inttypes.h and break the _("foo") macros) for uint32_t or ExifLong or
size_t - so we're probably best off if we make sure the format string is
large enough and provide the compiler with a value of the proper width.

That would mean we use

   "%lu", (unsigned long)(foo)
        for foo types of size_t, uint32_t, ExifLong
   "%li", (signed long)(foo)
        for foo types of ssize_t, int32_t, ExifSLong

right?

> 3) No, I don't know any compiler not supporting %li. Isn't it in the
>  C standard?

Which one? :)

I do not know, as I do not have any C standard documents.

> 4) However, I do know that 4=sizeof(int)<sizeof(long)=8 on 64bit
>   Windows, but 8=sizeof(int)=sizeof(long)=8 on 64bit Mac OS.
>   We have not declared 64bit support yet, but we will have to do so
>   very soon.

Where can 64bit be problematic?

Data structure size:
   Should not matter as we should be using uint8_t, uint16_t and
   uint32_t everywhere where size matters anyway. Right?

Calculations done with more precision:
   When we need an overflow, & 0xffffffff should fix that, right?

...

> 5) sizeof(int) indeed is not the same as sizeof(void*).

I remember the rule that sizeof(long) == sizeof(anything*). Whether that
is coincidence or definition, needs to be researched before building on it.

> 6) Q: do we still have to bother with 16bit int?

I would not go out of my way to prevent libexif from working with 16bit
int systems. If we use all the proper type definitions, 16bit int
systems should either just work or throw a compilation error.

Uli

Re: [Libexif-devel] [libexif-cvs] libexif/libexif/pentax mnote-pentax-entry.c, 1.11, 1.12

[Hans U. N. <gp...@n-...>]

Jan Patera wrote:

> I am sorry for replying that late. Actually what I did, was just
> a unification. I did not attempt to improve the messages as such,
> although I should have.

Hmm. What constitutes improvement?

Two kinds of improvement I could think of:

  a) Use a verbal phrase which is more or less unique and describing
     what went wrong. Possibly helpful to user for circumventing the
     problem, requires translating many technically complicated
     sentences which might not make sense to non-developer translators.

  b) _("Internal error %s"), "LE0051". That is also unique, does not
     require much phantasy while writing, only needs translating one
     specific string, and allows anyone with the source code to find
     out where the thing broke. The only question is how to allocate
     unique strings like "LE0051".

Any more ideas?

> All the texts I touched do get displayed to the user, they are
> not (hidden) log or debug messages. Some of them were terminated
> with dot (like a complete sentence) and some were not. Some
> were translated and some were not. After my changes, all should be
> translated and not terminated, to be consistent with all the other texts
> returned by mnote_*_entry_get_value().

OK, consistency is good.

> Yes, I think it gets better user experience. The users may also help us
> in registering new not-yet-known values of new cameras, if they clearly
> understand the situation. Not every user of SW using libexif speaks
> English. For example, many users of the Czech software I participate
> on don't speak English, but we do have good bug-reporting system
> from our users towards us. Actually this product and feedback from it
> is the reason why I joined the libexif team and why I do so many changes...

Oh. I was not aware of those non-English channels for user feedback...
probably due to my not speaking any Czech at all :)

Anyway, I am grateful for anything that works, so +1 on translating the
stuff.

Uli

Re: [Libexif-devel] Segfault / Leak - Exif 0.6.16

[Michele B. <mi...@pu...>]

* Jan Patera (pa...@pi...) wrote:
> Hi Michele,
>=20
> thnak you for reporting this problem. I checked in a fix in
> libexif/libexif/olympus/exif-mnote-data-olympus.c
> The maker note was wrongly interpreted on read due to the wrong
> word order (endianness). This caused wrong data sizes leading into
> possibly failing huge memory allocations.
>=20
<snip>

Hi Jan,

I checked the fix and it solves my issues.
I went ahead and closed #1742491 on SF.net.

Thanks *a lot* for your quick fix, you rock ;)

regards,
Michele

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.101, 1.102

[Jan P. <pa...@pi...>]

Hi,

I see we need several audits. One of them is for the types and formatting
sequences used.
1) libexif doesn't use size_t and ssize_t anywhere, except of exif-mem.c
  where the arguments to calloc and realloc are typecast to size_t
2) size members in all our structures are always unsigned int. Therefore
 I agree rather %u should be used, also to catch bugs and problems,
 like the recent iDefense problem and the Michele's report.
 Some functions use ExifLong which is supposed to be 32bit.
3) Again, I did unification - both %li and %i were used on different places
 in the same situation.
3) No, I don't know any compiler not supporting %li. Isn't it in the
 C standard?
4) However, I do know that 4=sizeof(int)<sizeof(long)=8 on 64bit
  Windows, but 8=sizeof(int)=sizeof(long)=8 on 64bit Mac OS.
  We have not declared 64bit support yet, but we will have to do so
  very soon.
5) sizeof(int) indeed is not the same as sizeof(void*).
6) Q: do we still have to bother with 16bit int?

 -- Jan

> Jan Patera wrote:
>
>> Index: exif-entry.c
>> ===================================================================
>> RCS file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
>> retrieving revision 1.101
>> retrieving revision 1.102
>> diff -u -p -d -r1.101 -r1.102
>> --- exif-entry.c	15 May 2007 18:23:28 -0000	1.101
>> +++ exif-entry.c	15 Jun 2007 06:49:42 -0000	1.102
>> @@ -863,7 +863,7 @@ exif_entry_get_value (ExifEntry *e, char
>>  	case EXIF_TAG_MAKER_NOTE:
>>  		CF (e, EXIF_FORMAT_UNDEFINED, val, maxlen);
>>  		snprintf (val, maxlen, _("%i bytes unknown data"),
>> -			  (int) e->components);
>> +			  e->size);
>>  		break;
>>  	case EXIF_TAG_SUBJECT_AREA:
>>  		CF (e, EXIF_FORMAT_SHORT, val, maxlen);
>
> Hmm. Does anyone have a proper reference on what format strings to use
> for what data type on what platform? I have <inttypes.h> here, which
> defines strings like PRIu32 as "u", and is supposed to be used to
> construct format strings, I suppose. However, we cannot use those
> together with gettext based translations, can we?
>
> (At least a few of) those "%li" format strings made sense. IIRC someone
> said pointer size was guaranteed to be equal to long, not to int. Thus
> %li would be proper for size_t and ssize_t as well.
>
> Jan, do you have a compiler which does not support %li?
>
> And in this case at hand, e->components is unsigned, so it should at
> least be an (unsigned int) and %u, not (int) and %i, right?
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> libexif-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] [libexif-cvs] libexif/libexif/pentax mnote-pentax-entry.c, 1.11, 1.12

[Jan P. <pa...@pi...>]

Hans,

I am sorry for replaying that late. Actually what I did, was just
a unification. I did not attempt to improve the messages as such,
although I should have.
All the texts I touched do get displayed to the user, they are
not (hidden) log or debug messages. Some of them were terminated
with dot (like a complete sentence) and some were not. Some
were translated and some were not. After my changes, all should be
translated and not terminated, to be consistent with all the other texts
returned by mnote_*_entry_get_value().
Yes, I think it gets better user experience. The users may also help us
in registering new not-yet-known values of new cameras, if they clearly
understand the situation. Not every user of SW using libexif speaks
English. For example, many users of the Czech software I participate
on don't speak English, but we do have good bug-reporting system
from our users towards us. Actually this product and feedback from it
is the reason why I joined the libexif team and why I do so many changes...

 -- Jan


>> --- mnote-pentax-entry.c	13 May 2007 19:21:47 -0000	1.11
>> +++ mnote-pentax-entry.c	24 May 2007 06:47:14 -0000	1.12
>> @@ -341,7 +341,7 @@ mnote_pentax_entry_get_value (MnotePenta
>>  			/* search the tag */
>>  			for (i = 0; (items[i].tag && items[i].tag != entry->tag); i++); if
>> (!items[i].tag) {
>> -			  	strncpy (val, "Internal error", maxlen);
>> +			  	strncpy (val, _("Internal error"), maxlen);
>>  			  	break;
>>  			}
>
> OK... so we have one of the worst error messages ever (because it does
> not give ANY hint as to what may have been the cause), and one which
> definitely needs developer attention to fix if a user sees it.
>
> Does it make the user experience better if that kind of message is
> translated? The language for discussions with the developers is mainly
> English, and we don't have translators for bug fixing discussions :)


>> @@ -350,7 +350,7 @@ mnote_pentax_entry_get_value (MnotePenta
>>  			    (items[i].elem[j].index < vs); j++);
>>  			if (items[i].elem[j].index != vs) {
>>  				snprintf (val, maxlen,
>> -					  "Internal error (unknown value %i)", vs);
>> +					  _("Internal error (unknown value %i)"), vs);
>>  				break;
>>  			}
>>  			strncpy (val, items[i].elem[j].string, maxlen);
>
> OK, that is a little better. At least some hint.

Re: [Libexif-devel] Segfault / Leak - Exif 0.6.16

[Jan P. <pa...@pi...>]

Hi Michele,

thnak you for reporting this problem. I checked in a fix in
libexif/libexif/olympus/exif-mnote-data-olympus.c
The maker note was wrongly interpreted on read due to the wrong
word order (endianness). This caused wrong data sizes leading into
possibly failing huge memory allocations.

 Kind regards,
                    Jan Patera


> Hi all,
>
> long story short. While using f-spot I stumbled into a 100%
> reproduceable crash:
>
>         /usr/lib/libexif.so.12(exif_set_short+0x2c) [0xb39119ac]
>         /usr/lib/libexif.so.12 [0xb3908d2f]
>         /usr/lib/libexif.so.12 [0xb390912b]
>         /usr/lib/libexif.so.12(exif_data_save_data+0x1bf) [0xb39096af]
>
> (The crash happens in exif_set_short, I *think* because
> exif_data_save_data has a corrupted data struct or data->priv)
>
> So I went ahead and installed gexif in order to make a smaller test
> case. Running gexif, loading the picture and then saving it again shows
> problems (leak plus seagfault). The leaks get pretty big (this is always
> just loading and saving an image in gexif without touching any values) :
>  2527 michele   18   0 2284m 1.6g 2032 T    0 80.3   0:02.96 gexif
>
> and then it crashes. Here is the full backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1218484544 (LWP 2527)]
> 0xb7f5895b in exif_set_sshort (b=0x1a6 <Address 0x1a6 out of bounds>,
> order=EXIF_BYTE_ORDER_MOTOROLA, value=-28026) at exif-utils.c:113
> 113                     b[0] = (unsigned char) (value >> 8);
> (gdb) bt full
> #0  0xb7f5895b in exif_set_sshort (b=0x1a6 <Address 0x1a6 out of
> bounds>, order=EXIF_BYTE_ORDER_MOTOROLA, value=-28026) at
> exif-utils.c:113
> No locals.
> #1  0xb7f589ac in exif_set_short (b=0x1a6 <Address 0x1a6 out of bounds>,
> order=EXIF_BYTE_ORDER_MOTOROLA, value=37510) at exif-utils.c:126
> No locals.
> #2  0xb7f4fd2f in exif_data_save_data_content (data=0x8207700,
> ifd=0x8205ba8, d=0xbfb59f04, ds=0xbfb59f08, offset=222) at
> exif-data.c:237
>         j = 16
>         n_ptr = <value optimized out>
>         n_thumb = <value optimized out>
>         i = EXIF_IFD_EXIF
> #3  0xb7f5012b in exif_data_save_data_content (data=0x8207700,
> ifd=0x8203100, d=0xbfb59f04, ds=0xbfb59f08, offset=142) at
> exif-data.c:555
>         j = 10
>         n_ptr = <value optimized out>
>         n_thumb = <value optimized out>
>         i = EXIF_IFD_0
> #4  0xb7f506af in exif_data_save_data (data=0x8207700, d=0xbfb59f04,
> ds=0xbfb59f08) at exif-data.c:947
>         fd = <value optimized out>
> #5  0x0804b211 in jpeg_data_save_data (data=0x81938e8, d=0xbfb59f3c,
> ds=0xbfb59f38) at jpeg-data.c:127
>         i = 1
>         eds = 2366559238
>         s = {marker = JPEG_MARKER_APP1, content = {generic = {data
> 0x8207700 "", size = 775305261}, app1 = 0x8207700}} ed =
> (unsigned char *) 0x0
> #6  0x0804b2dd in jpeg_data_save_file (data=0x81938e8, path=0x82076e0
> "/tmp/gexif/gexif/img-86.jpg") at jpeg-data.c:80
>         f = <value optimized out>
>         d = (unsigned char *) 0x81aaba0 "����X\213\037\b\020"
> size = 4
> #7  0x08049b9b in gexif_main_save_file (m=<value optimized out>,
> path=0x9286 <Address 0x9286 out of bounds>) at gexif-main.c:190
> No locals.
> #8  0xb7d17428 in ?? () from /usr//lib/libgtk-x11-2.0.so.0
> No symbol table info available.
> #9  0x0807b000 in ?? ()
> No symbol table info available.
> #10 0x00000000 in ?? ()
> No symbol table info available.
>
>
> Let me know if you need further info.
>
> thanks a lot for the library and regards,
> Michele Baldessari
>
> (culprit image is at http://michele.pupazzo.org/files/img-86.jpg)

Re: [Libexif-devel] Segfault / Leak - Exif 0.6.16

[Michele B. <mic...@pu...>]

* Michele Baldessari (mic...@pu...) wrote:
<snip>
> (culprit image is at http://michele.pupazzo.org/files/img-86.jpg)

And here's a small testcase, so you don't have to install gexif and
libexif-gtk:

http://michele.pupazzo.org/files/exif-bug.tgz

hth,
Michele

[Libexif-devel] Segfault / Leak - Exif 0.6.16

[Michele B. <mic...@pu...>]

Hi all,

long story short. While using f-spot I stumbled into a 100%
reproduceable crash:

        /usr/lib/libexif.so.12(exif_set_short+0x2c) [0xb39119ac]
        /usr/lib/libexif.so.12 [0xb3908d2f]
        /usr/lib/libexif.so.12 [0xb390912b]
        /usr/lib/libexif.so.12(exif_data_save_data+0x1bf) [0xb39096af]

(The crash happens in exif_set_short, I *think* because
exif_data_save_data has a corrupted data struct or data->priv)
=20
So I went ahead and installed gexif in order to make a smaller test
case. Running gexif, loading the picture and then saving it again shows
problems (leak plus seagfault). The leaks get pretty big (this is always
just loading and saving an image in gexif without touching any values) :
 2527 michele   18   0 2284m 1.6g 2032 T    0 80.3   0:02.96 gexif =20

and then it crashes. Here is the full backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218484544 (LWP 2527)]
0xb7f5895b in exif_set_sshort (b=3D0x1a6 <Address 0x1a6 out of bounds>,
order=3DEXIF_BYTE_ORDER_MOTOROLA, value=3D-28026) at exif-utils.c:113
113                     b[0] =3D (unsigned char) (value >> 8);
(gdb) bt full
#0  0xb7f5895b in exif_set_sshort (b=3D0x1a6 <Address 0x1a6 out of
bounds>, order=3DEXIF_BYTE_ORDER_MOTOROLA, value=3D-28026) at
exif-utils.c:113
No locals.
#1  0xb7f589ac in exif_set_short (b=3D0x1a6 <Address 0x1a6 out of bounds>,
order=3DEXIF_BYTE_ORDER_MOTOROLA, value=3D37510) at exif-utils.c:126
No locals.
#2  0xb7f4fd2f in exif_data_save_data_content (data=3D0x8207700,
ifd=3D0x8205ba8, d=3D0xbfb59f04, ds=3D0xbfb59f08, offset=3D222) at
exif-data.c:237
        j =3D 16
        n_ptr =3D <value optimized out>
        n_thumb =3D <value optimized out>
        i =3D EXIF_IFD_EXIF
#3  0xb7f5012b in exif_data_save_data_content (data=3D0x8207700,
ifd=3D0x8203100, d=3D0xbfb59f04, ds=3D0xbfb59f08, offset=3D142) at
exif-data.c:555
        j =3D 10
        n_ptr =3D <value optimized out>
        n_thumb =3D <value optimized out>
        i =3D EXIF_IFD_0
#4  0xb7f506af in exif_data_save_data (data=3D0x8207700, d=3D0xbfb59f04,
ds=3D0xbfb59f08) at exif-data.c:947
        fd =3D <value optimized out>
#5  0x0804b211 in jpeg_data_save_data (data=3D0x81938e8, d=3D0xbfb59f3c,
ds=3D0xbfb59f38) at jpeg-data.c:127
        i =3D 1
        eds =3D 2366559238
        s =3D {marker =3D JPEG_MARKER_APP1, content =3D {generic =3D {data =
=3D
0x8207700 "", size =3D 775305261}, app1 =3D 0x8207700}}
        ed =3D (unsigned char *) 0x0
#6  0x0804b2dd in jpeg_data_save_file (data=3D0x81938e8, path=3D0x82076e0
"/tmp/gexif/gexif/img-86.jpg") at jpeg-data.c:80
        f =3D <value optimized out>
        d =3D (unsigned char *) 0x81aaba0 "=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BDX\213\037\b\020"
        size =3D 4
#7  0x08049b9b in gexif_main_save_file (m=3D<value optimized out>,
path=3D0x9286 <Address 0x9286 out of bounds>) at gexif-main.c:190
No locals.
#8  0xb7d17428 in ?? () from /usr//lib/libgtk-x11-2.0.so.0
No symbol table info available.
#9  0x0807b000 in ?? ()
No symbol table info available.
#10 0x00000000 in ?? ()
No symbol table info available.


Let me know if you need further info.=20

thanks a lot for the library and regards,
Michele Baldessari

(culprit image is at http://michele.pupazzo.org/files/img-86.jpg)

Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.101, 1.102

[Hans U. N. <gp...@n-...>]

Jan Patera wrote:

> Index: exif-entry.c
> ===================================================================
> RCS file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
> retrieving revision 1.101
> retrieving revision 1.102
> diff -u -p -d -r1.101 -r1.102
> --- exif-entry.c	15 May 2007 18:23:28 -0000	1.101
> +++ exif-entry.c	15 Jun 2007 06:49:42 -0000	1.102
> @@ -863,7 +863,7 @@ exif_entry_get_value (ExifEntry *e, char
>  	case EXIF_TAG_MAKER_NOTE:
>  		CF (e, EXIF_FORMAT_UNDEFINED, val, maxlen);
>  		snprintf (val, maxlen, _("%i bytes unknown data"),
> -			  (int) e->components);
> +			  e->size);
>  		break;
>  	case EXIF_TAG_SUBJECT_AREA:
>  		CF (e, EXIF_FORMAT_SHORT, val, maxlen);

Hmm. Does anyone have a proper reference on what format strings to use
for what data type on what platform? I have <inttypes.h> here, which
defines strings like PRIu32 as "u", and is supposed to be used to
construct format strings, I suppose. However, we cannot use those
together with gettext based translations, can we?

(At least a few of) those "%li" format strings made sense. IIRC someone
said pointer size was guaranteed to be equal to long, not to int. Thus
%li would be proper for size_t and ssize_t as well.

Jan, do you have a compiler which does not support %li?

And in this case at hand, e->components is unsigned, so it should at
least be an (unsigned int) and %u, not (int) and %i, right?

[Libexif-devel] New Vietnamese PO file for `libexif'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `libexif',
has been submitted by the team of translators taking care of the
Vietnamese language.  This particular file, along with all other PO
files pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/libexif/vi.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/libexif/vi.po
>    http://translation.sf.net/maint/libexif/vi.po

We may arrange things so future such files be automatically e-mailed
to you when they arrive.  Ask to the address below if you want this.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-libexif.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[Libexif-devel] New German PO file for `libexif'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `libexif',
has been submitted by the team of translators taking care of the
German language.  This particular file, along with all other PO files
pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/libexif/de.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/libexif/de.po
>    http://translation.sf.net/maint/libexif/de.po

We may arrange things so future such files be automatically e-mailed
to you when they arrive.  Ask to the address below if you want this.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-libexif.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[Libexif-devel] New Polish PO file for `libexif'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A revised PO file, for programs using the textual domain `libexif',
has been submitted by the team of translators taking care of the
Polish language.  This particular file, along with all other PO files
pertaining to the same textual domain, is available as:
>    http://www.iro.umontreal.ca/translation/maint/libexif/pl.po

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/maint/libexif/pl.po
>    http://translation.sf.net/maint/libexif/pl.po

We may arrange things so future such files be automatically e-mailed
to you when they arrive.  Ask to the address below if you want this.

The following HTML page should also be updated by tomorrow.

>    http://www.iro.umontreal.ca/translation/HTML/domain-libexif.html

Please consider including all PO files, as they stand, in the `po/'
subdirectory of your next release of programs using that textual domain,
whether it is official or pretest.  Whenever you have a distribution ready
which holds a newer PO Template, please send the URL of this distribution
to the address below.  The distribution could be a pretest or a snapshot,
it does not even have to compile.  This is to be used by translators,
when they need to get some translation context from your sources.

Within the Translation Project, each PO Template file should have different
version numbers, but since it is not OK to have two different distributions
using same version numbers, this is not a problem in practice.

Contact me if any question arises.  Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

[Libexif-devel] New PO Template file for `libexif'

[Translation P. R. <tra...@ir...>]

Hello, gentle maintainer. This is a message from the Translation
Project robot.

A new PO Template file, for programs using the textual domain
`libexif', has just been made available to language teams for
translation, and a copy is available as:
>    http://www.iro.umontreal.ca/translation/domains/POT/libexif-0.6.16.pot

The file should soon be made available in mirror sites as:

>    ftp://ftp.unex.es/pub/gnu-i18n/po/domains/POT/libexif-0.6.16.pot
>    http://translation.sf.net/domains/POT/libexif-0.6.16.pot


In your releases, this file is usually found as `po/libexif.pot'.  It
is created or updated automatically at `make dist' time, or whenever
you run `make update-po' in the `po/' subdirectory.  Whenever you have
a distribution ready which holds a newer PO Template, please send the
URL of this distribution to the address below.  The distribution could
be a pretest or a snapshot, it does not even have to compile.  This is
to be used by translators, when they need to get some translation
context from your sources.

Within the Translation Project, each PO Template file should have
different version numbers, but since it is not OK to have two
different distributions having same version numbers, this is not a
problem in practice.
Here is the URL information which has just been provided to translators for
your package.  Please inform the translation coordinator, at the address
given below, if the information does not appear to be adequate or current:

>    http://ftp1.sourceforge.net/sourceforge/libexif/libexif-0.6.16.tar.bz2

We can arrange things so translated PO files be automatically e-mailed
to you when they arrive.  Ask to the address below if you want this.

Thanks for your collaboration,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                mailto:tra...@ir...

Re: [Libexif-devel] New Polish PO file for `libexif'

[Marcus M. <ma...@je...>]

On Wed, Jun 13, 2007 at 01:32:30PM +0200, Hans Ulrich Niedermann wrote:
> Translation Project Robot wrote:
> > Hello, gentle maintainer. This is a message from the Translation
> > Project robot.
> > 
> > A revised PO file, for programs using the textual domain `libexif',
> > has been submitted by the team of translators taking care of the
> > Polish language.  This particular file, along with all other PO files
> > pertaining to the same textual domain, is available as:
> >>    http://www.iro.umontreal.ca/translation/maint/libexif/pl.po
> 
> This seems to be the exact stuff Jakub has submitted a few days ago and
> which we have had in CVS ever since.

Its likely he submitted it to the translation project too.

Ciao, Marcus

Re: [Libexif-devel] New Polish PO file for `libexif'

[Hans U. N. <gp...@n-...>]

Translation Project Robot wrote:
> Hello, gentle maintainer. This is a message from the Translation
> Project robot.
> 
> A revised PO file, for programs using the textual domain `libexif',
> has been submitted by the team of translators taking care of the
> Polish language.  This particular file, along with all other PO files
> pertaining to the same textual domain, is available as:
>>    http://www.iro.umontreal.ca/translation/maint/libexif/pl.po

This seems to be the exact stuff Jakub has submitted a few days ago and
which we have had in CVS ever since.