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

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

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

On Thu, 2005-03-17 at 16:09 +0100, Hans Ulrich Niedermann wrote:
> But, after seeing the complete code in question, I'd just do away
> completely with "be" and "le", and call it "cmp_intel_func" and
> "cmp_motorola_func".

Even more confusing.

Hub
-- 
Crazy French - http://www.figuiere.net/hub/

Re: [Libexif-devel] autogen.sh

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

Hans Ulrich Niedermann <gp...@n-...> writes:

> Lutz M=C3=BCller <lu...@us...> writes:

>> Making all in m4
>> make[2]: Entering directory `/home/lutz/build/libexif/m4'
>> make[2]: Nothing to be done for `all'.
>> make[2]: Leaving directory `/home/lutz/build/libexif/m4'
>> Making all in po
>> make[2]: Entering directory `/home/lutz/build/libexif/po'
>> make[2]: *** No rule to make target `/config.status', needed by
>> `Makefile'.  Stop.
>> make[2]: Leaving directory `/home/lutz/build/libexif/po'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/lutz/build/libexif'
>> make: *** [all] Error 2
>>
>> I usually remove po from SUBDIRS in libexif/Makefile, but perhaps
>> someone knows the solution?
>
> Not yet, but remain assured that I'll find one.

Fixed.

But I'm confused why I haven't run into that problem until you
reported it. I've been doing out-of-tree builds all the time.

Uli

Re: [Libexif-devel] autogen.sh

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

Lutz M=C3=BCller <lu...@us...> writes:

> cvs co libexif
> cd libexif
> ./autogen.sh
> cd .. && mkdir build && cd build
> ../libexif/configure
> make
>
> make fails with:
>
> lutz@lutz:~/build/libexif$ make
> make  all-recursive
> make[1]: Entering directory `/home/lutz/build/libexif'
> Making all in m4
> make[2]: Entering directory `/home/lutz/build/libexif/m4'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/lutz/build/libexif/m4'
> Making all in po
> make[2]: Entering directory `/home/lutz/build/libexif/po'
> make[2]: *** No rule to make target `/config.status', needed by
> `Makefile'.  Stop.
> make[2]: Leaving directory `/home/lutz/build/libexif/po'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/lutz/build/libexif'
> make: *** [all] Error 2
>
> I usually remove po from SUBDIRS in libexif/Makefile, but perhaps
> someone knows the solution?

Not yet, but remain assured that I'll find one.

Uli

[Libexif-devel] autogen.sh

[Lutz <lu...@us...>]

Hello!

When doing

cvs co libexif
cd libexif
./autogen.sh
cd .. && mkdir build && cd build
../libexif/configure
make

make fails with:

lutz@lutz:~/build/libexif$ make
make  all-recursive
make[1]: Entering directory `/home/lutz/build/libexif'
Making all in m4
make[2]: Entering directory `/home/lutz/build/libexif/m4'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/lutz/build/libexif/m4'
Making all in po
make[2]: Entering directory `/home/lutz/build/libexif/po'
make[2]: *** No rule to make target `/config.status', needed by
`Makefile'.  Stop.
make[2]: Leaving directory `/home/lutz/build/libexif/po'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/lutz/build/libexif'
make: *** [all] Error 2

I usually remove po from SUBDIRS in libexif/Makefile, but perhaps
someone knows the solution?

Regards
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Request for test images

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

Hi,

to expand the libexif testsuite we need test images. And we need your
help in that, because we don't have all the cameras available.

I'd like to ask you to privately send me (i.e. to gp...@n-...,
NOT to the mailing list) pictures taken with different cameras.

I'll keep a list of the images I have received so far on

   http://es.lauft.net/libexif-test-image-list

for a while. If this page is unreachable or too long to load, consider
this image collection project to be finished.

To reduce the file size, please

  1. use the lowest resolution possible (640x480 will do fine)
  2. use the lowest possible compression quality
  3. take a picture of pure black, i.e. with the lens lid held to the
     front of the lens or something like that

I'll then remove the owner string from the file with a hex editor
(unless you want me to leave it in) and add the image to the
testsuite.

Then we can run exif automatically on all of those images and check
that it handles them.

This will not yet allow us to systematically test special EXIF
features, but it will be a good start IMHO.

Thank you for your help.

Uli

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

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

"Jan Patera" <pa...@pi...> writes:

> I never remember which is little-endian and which is big-endian.

Same with me :-)

> And I must admit I didn't decipher the _be_ and _le_ letter in the
> function names :-(
>
> In any case Lutz's code was wrong:
> ==============
> static int
>    cmp_be_func (const void *elem1, const void *elem2)
>    {
>            return cmp_func ((const unsigned char *) elem1,
>                            (const unsigned char *) elem2,
> EXIF_BYTE_ORDER_INTEL);
>    }
>
>    static int
>    cmp_le_func (const void *elem1, const void *elem2)
>    {
>            return cmp_func ((const unsigned char *) elem1,
>                            (const unsigned char *) elem2,
> EXIF_BYTE_ORDER_MOTOROLA);
>    }
>
> ==============
> data->priv->order == EXIF_BYTE_ORDER_INTEL ? cmp_le_func : cmp_be_func
> ==============
>
> Are you saying I should have changed bodies of cmp_le_func & cmp_be_func
> instead?

I would have renamed the definition of the functions and exchanged
"be" and "le" :-)

But, after seeing the complete code in question, I'd just do away
completely with "be" and "le", and call it "cmp_intel_func" and
"cmp_motorola_func".

OK, let's wait for the CVS server to come back online.

Uli

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

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

I never remember which is little-endian and which is big-endian.
And I must admit I didn't decipher the _be_ and _le_ letter in the
function names :-(

In any case Lutz's code was wrong:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
static int
   cmp_be_func (const void *elem1, const void *elem2)
   {
           return cmp_func ((const unsigned char *) elem1,
                           (const unsigned char *) elem2,
EXIF_BYTE_ORDER_INTEL);
   }

   static int
   cmp_le_func (const void *elem1, const void *elem2)
   {
           return cmp_func ((const unsigned char *) elem1,
                           (const unsigned char *) elem2,
EXIF_BYTE_ORDER_MOTOROLA);
   }

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
data->priv->order =3D=3D EXIF_BYTE_ORDER_INTEL ? cmp_le_func : cmp_be_fun=
c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Are you saying I should have changed bodies of cmp_le_func & cmp_be_func
instead?

 -- Jan


> Jan Patera <pa...@us...> writes:
>
>> Update of /cvsroot/libexif/libexif/libexif
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19628
>>
>> Modified Files:
>> 	exif-data.c
>> Log Message:
>> Corrected byte ordering when sorting tags.
>>
>>
>> Index: exif-data.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> RCS file: /cvsroot/libexif/libexif/libexif/exif-data.c,v
>> retrieving revision 1.70
>> retrieving revision 1.71
>> diff -u -d -r1.70 -r1.71
>> --- exif-data.c	16 Mar 2005 07:33:05 -0000	1.70
>> +++ exif-data.c	17 Mar 2005 07:43:39 -0000	1.71
>> @@ -576,7 +576,7 @@
>>  	/* Sort the directory according to TIFF specification */
>>  	qsort (*d + 6 + offset - (ifd->count + n_ptr + n_thumb) * 12,
>>  			(ifd->count + n_ptr + n_thumb), 12,
>> -			data->priv->order =3D=3D EXIF_BYTE_ORDER_INTEL ? cmp_le_func :
>> cmp_be_func); +			data->priv->order =3D=3D EXIF_BYTE_ORDER_INTEL ?
>> cmp_be_func : cmp_le_func);
>>
>>  	/* Correctly terminate the directory */
>>  	if (i =3D=3D EXIF_IFD_0 && (data->ifd[EXIF_IFD_1]->count ||
>
> I thought Intel byte order was little endian?
>
> Uli
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Libexif-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel

[Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-data.c,1.70,1.71

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

Jan Patera <pa...@us...> writes:

> Update of /cvsroot/libexif/libexif/libexif
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19628
>
> Modified Files:
> 	exif-data.c 
> Log Message:
> Corrected byte ordering when sorting tags.
>
>
> Index: exif-data.c
> ===================================================================
> RCS file: /cvsroot/libexif/libexif/libexif/exif-data.c,v
> retrieving revision 1.70
> retrieving revision 1.71
> diff -u -d -r1.70 -r1.71
> --- exif-data.c	16 Mar 2005 07:33:05 -0000	1.70
> +++ exif-data.c	17 Mar 2005 07:43:39 -0000	1.71
> @@ -576,7 +576,7 @@
>  	/* Sort the directory according to TIFF specification */
>  	qsort (*d + 6 + offset - (ifd->count + n_ptr + n_thumb) * 12,
>  			(ifd->count + n_ptr + n_thumb), 12,
> -			data->priv->order == EXIF_BYTE_ORDER_INTEL ? cmp_le_func : cmp_be_func);
> +			data->priv->order == EXIF_BYTE_ORDER_INTEL ? cmp_be_func : cmp_le_func);
>  
>  	/* Correctly terminate the directory */
>  	if (i == EXIF_IFD_0 && (data->ifd[EXIF_IFD_1]->count ||

I thought Intel byte order was little endian?

Uli

[Libexif-devel] libexif 0.6.12 released

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

New in 0.6.12 (2005-03-13) since 0.6.11 (2004-10-16):

  * Final fix of Ubuntu Security Notice USN-91-1 (CAN-2005-0664)
    https://bugzilla.ubuntulinux.org/show_bug.cgi?id=7152

  * Updated build system with cross compile capabilities

  * Small fixes:
    Fix tag order, use even offsets, improve Nikon&Olympus mnote tags.

Release page:

http://sourceforge.net/project/showfiles.php?group_id=12272&package_id=38136&release_id=312422

MD5 sums:

69501aaf0862a79aaeeb73e81e8c1306  libexif-0.6.12.tar.gz
9f952ee8db0be7c53a075c34e8286d91  libexif-0.6.12.tar.bz2

SHA1 sums:

71d0aea509acac42337f7243c2cf435774df1769  libexif-0.6.12.tar.gz
5d2c5976521e179d41ff8908b678b14f2e8e690b  libexif-0.6.12.tar.bz2

CVS download:

   cvs -z3 -d:pserver:ano...@cv...:/cvsroot/libexif \
       co -P -r libexif-0_6_12-release libexif

Re: [Libexif-devel] libexif-0.6.12 release candidate tarball

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

Hans Ulrich Niedermann <gp...@n-...> writes:

> feel yourselves invited to check (i.e. build, cross-compile, test,
> read docs, feed to your dog, etc.) my proposed libexif-0.6.12 release
> tarballs from http://es.lauft.net/libexif-RC/

OK, Arnaud and I tested them, here are the results:

 1. Arnaud quickly found a flaw with expr syntax while building which
    caused configure output to look bad. This is fixed.

 2. Then, I tried to write a test case to check that message
    translation works correctly and discovered:

    a) The existing programs in test/ aren't used at all at
       "make check" time, so libexif still contains no checks.

       We should write a few shell scripts to use those binaries and
       add them to TESTS. This is nothing release critical, though.

    b) The translation support is currently broken, and that is
       release critical. I'm currently writing a test case and will
       only release libexif when I have a working test case.

Gru=C3=9F,

Uli

[Libexif-devel] libexif-0.6.12 release candidate tarball

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

Hi,

feel yourselves invited to check (i.e. build, cross-compile, test,
read docs, feed to your dog, etc.) my proposed libexif-0.6.12 release
tarballs from http://es.lauft.net/libexif-RC/

(Jan: We'll figure out the stdint suff within the next few days and
      release 0.6.13 shortly with revisded stdint, OK?)

Gru=C3=9F,

Uli

Re: [Libexif-devel] Re: Ubuntu; int16_t

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

"Jan Patera" <pa...@pi...> writes:

>> The Ubuntu thing seems to have spawned a flurry of activity in other
>> areas. Is that stable, or should I create a branch with the Ubuntu fix,
>> but without all the other changes?
>
> Absolutely stable. No need for any branching. There are no undergoing
> changes that would need any stabilization.

Good, then let's find out how to do the stdint.h stuff, and then
release 0.6.12.

>>> May I ask you (or somebody else) to update the configure scripts to
>>> generate also the definition of int16_t (signed 16 bit) in _stdint.h?
>>> Thanks.
>>
>> You'll have to help me there:
>>
>>   - What should int16_t be defined as?
>
> signed 16 bit integer (usually called short).

As far as I can tell, our generated _stdint.h either includes
definitions for all uint{8,16,32}_t and int{8,16,32}_t by including
the proper system file defining them or none at all.

>>   - Or where is int16_t defined on your system?

> Nowhere.

What system is that? OS/Compiler/make/...?

> exif-utils.h was already using uint16_t, uint32_t
> and int32_t. I just added int16_t for consistency (to typedef
> ExifSShort).

Good idea.

> I am not a *nix developer, therefore I am not much familiar with
> the (auto)configuration process. However, upto my understanding, all
> these types are defined in _stdint.h which is automatically generated
> by the configure script.

Explanation of our current _stdint.h generation:

According to C99, your C runtime should define those types in
stdint.h. However, if your system isn't C99 compatible, we try to fall
back on a number of non-standard (Unix) header files like inttypes.h.

Our current way to generate _stdint.h is a simplified version of
AC_CREATE_STDINT_H[1] from http://ac-archive.sourceforge.net/
written by Dan Fandrich for libgphoto2.

libgphoto2 is still a Unix centric library, so we don't really have to
deal with non-Unix systems there. libexif is a different case, though,
because a number of people use it on non-Unix systems.


Finding a solution:

It makes sense for libexif to ship a exif-stdint.h which adds the
"proper" integer definitions for your system if you don't have one of
the "standard" header files providing them.

Ideally, we would be able to ship a static exif-stdint.h file which
doesn't have to be modified by and configuration script and figures
out what to do purely using preprocessor magic.

Unfortunately, this is not possible, so we have to generate that
exif-stdint.h file at ./configure time using AC_CREATE_STDINT_H[1]
(yes, that seems to work with cross-compilation). This raises the
question of whether your system actually supports running ./configure:

  - Linux/BSD/Unix/MacOSX have the proper environment anyway
  - Windows has mingw
  - OS/2 afaik has a way to install bash&co, too.
  - other systems? no idea.

This still leaves open whether the results of such a configure run are
suitable to use with other compilers like Watcom or MSVC.

For systems not capable of running ./configure, we can only ship a few
example files and documentation telling people what to do with them
(like the stuff in contrib/watcom).


My Proposal:

Use the full AC_CREATE_STDINT_H[1] for libexif and create a
exif-stdint.h which is installed when installing libexif headers.

Also ship exif-stdint.h for a number of common special cases, together
with a README.stdint explaining the problem. Those common special
cases would probably be=20

   - 8/16/32 bit integers as char/short/int
   - 8/16/32 bit integers as char/int/long

using "unsigned foo" and "signed foo" for the (un)signed versions.

Would that be OK for you, Jan?


> My manually edited _stdint.h contains this:
> #ifndef __STDINT_H
> #define __STDINT_H
>
> typedef unsigned char   uint8_t;
> typedef unsigned short  uint16_t;
> typedef signed short    int16_t;
> typedef unsigned int    uint32_t;
> typedef signed int      int32_t;
>
> #endif /*!__STDINT_H*/

This is a fairly common way to define these types, and
contrib/watcom/_stdint.h basically contains this now. I took the
liberty to also add a signed int8_t for completeness' sake.

[1] http://ac-archive.sourceforge.net/C_Support/ac_create_stdint_h.html

Gru=C3=9F,

Uli

Re: [Libexif-devel] Re: Ubuntu; int16_t

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

> The Ubuntu thing seems to have spawned a flurry of activity in other
> areas. Is that stable, or should I create a branch with the Ubuntu fix,
> but without all the other changes?

Absolutely stable. No need for any branching. There are no undergoing
changes that would need any stabilization.

>> May I ask you (or somebody else) to update the configure scripts to
>> generate also the definition of int16_t (signed 16 bit) in _stdint.h?
>> Thanks.
>
> You'll have to help me there:
>
>   - What should int16_t be defined as?

signed 16 bit integer (usually called short).

>   - Or where is int16_t defined on your system?

Nowhere. exif-utils.h was already using uint16_t, uint32_t
and int32_t. I just added int16_t for consistency (to typedef
ExifSShort).
I am not a *nix developer, therefore I am not much familiar with
the (auto)configuration process. However, upto my understanding, all
these types are defined in _stdint.h which is automatically generated
by the configure script.

My manually edited _stdint.h contains this:
#ifndef __STDINT_H
#define __STDINT_H

typedef unsigned char   uint8_t;
typedef unsigned short  uint16_t;
typedef signed short    int16_t;
typedef unsigned int    uint32_t;
typedef signed int      int32_t;

#endif /*!__STDINT_H*/

> As far as I can see, we're not defining any int types ourselves, but
> rather just check for them in a number of header files, and just
> #include the right one.

 -- Jan

Re: [Libexif-devel] Re: Ubuntu; int16_t

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

"Jan Patera" <pa...@pi...> writes:

> yes this patch fixed what was still not yet fixed of the Ubunyu bug.

OK, sounds like release time. :-)

The Ubuntu thing seems to have spawned a flurry of activity in other
areas. Is that stable, or should I create a branch with the Ubuntu
fix, but without all the other changes?

> May I ask you (or somebody else) to update the configure scripts
> to generate also the definition of int16_t (signed 16 bit) in _stdint.h?
> Thanks.

You'll have to help me there:

  - What should int16_t be defined as?

  - Or where is int16_t defined on your system?

As far as I can see, we're not defining any int types ourselves, but
rather just check for them in a number of header files, and just
#include the right one.

Gru=C3=9F,

Uli

Re: [Libexif-devel] Re: [libexif-cvs] libexif/test test-mem.c,1.6,1.7

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

"Jan Patera" <pa...@pi...> writes:

> shouldn't "size[1] =3D ebs << 8;" be in fact
> "size[1] =3D ebs >> 8;"? Perhaps some (unsigned char) typecasts
> would also be nice to avoid compiler warnings.

Perhaps better (uint8_t) types and typecasts?

Gru=C3=9F,

Uli

[Libexif-devel] Re: Ubuntu; int16_t

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

Hi Hans,

yes this patch fixed what was still not yet fixed of the Ubunyu bug.

May I ask you (or somebody else) to update the configure scripts
to generate also the definition of int16_t (signed 16 bit) in _stdint.h?
Thanks.

 --- Jan

> Jan Patera <pa...@us...> writes:
>
>> Update of /cvsroot/libexif/libexif/libexif
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1237/libexif
>>
>> Modified Files:
>> 	exif-data.c
>> Log Message:
>> 2005-03-09  Jan Patera <pa...@us...>
>> 	* exif_data.c: Final fix of Ubuntu Security Notice USN-91-1
>> 	  https://bugzilla.ubuntulinux.org/show_bug.cgi?id=3D7152
>> 	  Most of the problem (including most important parts) was
>> 	  already fixed in the past.
>>
>>
>> Index: exif-data.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
>> RCS file: /cvsroot/libexif/libexif/libexif/exif-data.c,v retrieving
>> revision 1.62
>> retrieving revision 1.63
>> diff -u -d -r1.62 -r1.63
>> --- exif-data.c	16 Dec 2004 21:00:26 -0000	1.62
>> +++ exif-data.c	9 Mar 2005 06:02:45 -0000	1.63
>> @@ -696,7 +696,7 @@
>>  		  "Found EXIF header.");
>>
>>  	/* Byte order (offset 6, length 2) */
>> -	if (ds < 12)
>> +	if (ds < 14)
>>  		return;
>>  	if (!memcmp (d + 6, "II", 2))
>>  		data->priv->order =3D EXIF_BYTE_ORDER_INTEL;
>> @@ -714,7 +714,7 @@
>>  	exif_log (data->priv->log, EXIF_LOG_CODE_DEBUG, "ExifData",
>>  		  "IFD 0 at %i.", (int) offset);
>>
>> -	/* Parse the actual exif data (offset 14) */
>> +	/* Parse the actual exif data (usually offset 14 from start) */
>>  	exif_data_load_data_content (data, data->ifd[EXIF_IFD_0], d + 6,
>>  				     ds - 6, offset);
>
> Does this fix everything now? :-)
>
> Tell me if/when we should do another release.
>
> (Yes, a test case would be nice.)
>
> Gru=C3=9F,
>
> Uli
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=EFick
> _______________________________________________
> Libexif-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel

[Libexif-devel] Re: [libexif-cvs] libexif/test test-mem.c,1.6,1.7

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

Hi Lutz,

shouldn't "size[1] =3D ebs << 8;" be in fact
"size[1] =3D ebs >> 8;"? Perhaps some (unsigned char) typecasts
would also be nice to avoid compiler warnings.

Regards,
       -- Jan


> Update of /cvsroot/libexif/libexif/test
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24021/test
>
> Modified Files:
> 	test-mem.c
> Log Message:
> 2005-03-09  Lutz Mueller <lu...@us...>
>
> 	* test/test-mem.c: Write size to loader to make the test work again.
>
>
> Index: test-mem.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS
> file: /cvsroot/libexif/libexif/test/test-mem.c,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -u -d -r1.6 -r1.7
> --- test-mem.c	31 Aug 2004 06:11:03 -0000	1.6
> +++ test-mem.c	9 Mar 2005 22:03:18 -0000	1.7
> @@ -32,7 +32,7 @@
>  {
>  	ExifData *ed;
>  	ExifEntry *e;
> -	unsigned char *eb;
> +	unsigned char *eb, size[2];
>  	unsigned int ebs;
>  	ExifLoader *loader;
>  	unsigned int i;
> @@ -66,6 +66,9 @@
>
>  	printf ("Writing %i byte(s) EXIF data to loader...\n", ebs);
>  	loader =3D exif_loader_new ();
> +	size[0] =3D ebs;
> +	size[1] =3D ebs << 8;
> +	exif_loader_write (loader, size, 2);
>  	for (i =3D 0; i < ebs && exif_loader_write (loader, eb + i, 1); i++);
> printf ("Wrote %i byte(s).\n", i);
>  	free (eb);
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> libexif-cvs mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-cvs

[Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-data.c,1.62,1.63

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

Jan Patera <pa...@us...> writes:

> Update of /cvsroot/libexif/libexif/libexif
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1237/libexif
>
> Modified Files:
> 	exif-data.c=20
> Log Message:
> 2005-03-09  Jan Patera <pa...@us...>
> 	* exif_data.c: Final fix of Ubuntu Security Notice USN-91-1
> 	  https://bugzilla.ubuntulinux.org/show_bug.cgi?id=3D7152
> 	  Most of the problem (including most important parts) was
> 	  already fixed in the past.
>
>
> Index: exif-data.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/libexif/libexif/libexif/exif-data.c,v
> retrieving revision 1.62
> retrieving revision 1.63
> diff -u -d -r1.62 -r1.63
> --- exif-data.c	16 Dec 2004 21:00:26 -0000	1.62
> +++ exif-data.c	9 Mar 2005 06:02:45 -0000	1.63
> @@ -696,7 +696,7 @@
>  		  "Found EXIF header.");
>=20=20
>  	/* Byte order (offset 6, length 2) */
> -	if (ds < 12)
> +	if (ds < 14)
>  		return;
>  	if (!memcmp (d + 6, "II", 2))
>  		data->priv->order =3D EXIF_BYTE_ORDER_INTEL;
> @@ -714,7 +714,7 @@
>  	exif_log (data->priv->log, EXIF_LOG_CODE_DEBUG, "ExifData",=20
>  		  "IFD 0 at %i.", (int) offset);
>=20=20
> -	/* Parse the actual exif data (offset 14) */
> +	/* Parse the actual exif data (usually offset 14 from start) */
>  	exif_data_load_data_content (data, data->ifd[EXIF_IFD_0], d + 6,
>  				     ds - 6, offset);

Does this fix everything now? :-)

Tell me if/when we should do another release.

(Yes, a test case would be nice.)

Gru=C3=9F,

Uli

[Libexif-devel] Fwd: USN-91-1: EXIF library vulnerability

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

Hi,

I've just stumbled upon

  Ubuntu Security Notice USN-91-1 March 07, 2005
  libexif vulnerabilities
  https://bugzilla.ubuntulinux.org/7152=20

and as I can't remember having read anything about this issue here, I
am writing this mail.

This notice appears to address a problem in libexif 0.6.9, and the
code in dispute has been rewritten since. Therefore, I am not sure
whether our current code is still vulnerable or not.

Further references for the people with code knowledge to read through:

  http://www.ubuntulinux.org/support/documentation/usn/usn-91-1
  https://bugzilla.ubuntulinux.org/show_bug.cgi?id=3D7152
  https://bugzilla.ubuntu.com/attachment.cgi?id=3D1508

(I don't know the code. I just help to build the beast :-)

Gru=C3=9F,

Uli

[Libexif-devel] Revised libexif build system (new autogen.sh, no more gettextize)

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

Hi,

I have started to do something libexif, libgphoto2 and Co. have needed
for quite some time: To get away from the ugly autogen.sh solution
using gettextize (you will remember that forced manual keypress).

You can read ChangeLog and the CVS log messages to libexif-cvs for the
complete details, but I'll write a short summary here:

Usage:

  cvs co libexif
  cd libexif

  ./autogen.sh
  ./configure --prefix=3D/foo
  make check
  make install

  make uninstall
  make distclean
  ./autogen.sh --clean

  and you should have a system which is clean again :)

Changes:
  =3D complete redesign of autogen.sh
  + use autoreconf (comes with autoconf) to automagically do the right
    thing instead of home-brewn solution manually calling autoconf,
    aclocal, autoheader, libtoolize, gettextize, etc.
  + autoreconf calls autopoint instead of gettextize - no more
    keypresses while building, no more modifications of configure.in,
    Makefile.am, ChangeLog.
  + moved a number of common definitions from the single Makefile.am
    files to a central place - configure.in.
  + misc. small stuff
  - Downside: Building from CVS requires a newer toolset.
    Too old are: autoconf 2.50, automake 1.4, gettext < 0.14.1
    autoconf 2.59, automake 1.8 and gettext 0.14.1 will work find, and
    have been releases more than a year ago.

What works:
  + intl/ gets shipped, unlike 0.6.11
  + Building a .so library on Linux works flawlessly (tested)
  + I can build a Windows DLL file without NLS support
      + on a Linux system using a MinGW crosscompiler (tested)
      + on a Windows system using Cygwin (tested)
  + You can now build in the CVS tree without having something modify
    existing files (OK, the *.po files don't count :)

What doesn't work:
  - The included libintl doesn't use libtool to build, which makes it
    non-trivial to build a DLL with intl support. So Windows users
    will have to live without i18n for now.
  - Building from CVS with antique build tool set. Considering the age
    of the supported tools and that libexif addresses developers not
    end users, this should be acceptable.

A word on the Windows support:
  Windows is an environment which is very unfriendly to programmers
  according to my personal experience. This means that I (personally)
  don't intend to create or maintain a real Windows port or something
  like that, but the new build system builds for Windows without any
  additional costs, so I'm fine with that.

I think this is a lot better than the stuff we had previously, but I'd
appreciate any feedback - be it positive or negative (degradation).

If this thing works out well here, I'd like to move

  * exif, libexif-gtk, gexif and
  * libgphoto2, gphoto2, gtkam

to the same autogen.sh script and do the corresponding changes to
configure.in and **/Makefile.am over the next few weeks and months.

I've just started with libexif because libexif is quite small, and
libexif development currently isn't all that hectic.

Gru=C3=9F,

Uli

=2D-=20
Some gphoto2 links: http://www.teaser.fr/~hfiguiere/linux/digicam.html
http://gphoto.sf.net/        http://n-dimensional.de/projects/digicam/
#gphoto on irc.freenode.net              http://sf.net/projects/gphoto
http://sf.net/projects/libusb           http://sf.net/projects/libexif

[Libexif-devel] Trouble compiling libexif-0.6.11

[gerhard\.schiller <ger...@la...>]

Hello, 

while trying to compile libexif-0.6.11 on Fedora Core 3 I got the followi=
ng error:

/home/gerhard/Kamera/libexif-0.6.11
Making all in po
make[2]: Entering directory `/home/gerhard/Kamera/libexif-0.6.11/po'
make[2]: *** Keine Regel, um "all" zu erstellen.  Schluss.

where the last line translates (roughly) to:
make[2]: *** no rule to make "all", stop

I had to remove 'po' from the list of subdir's to finish make.

Gerhard=0A=0AAcc=E9dez au courrier =E9lectronique de La Poste : www.lapos=
te.net ; =0A3615 LAPOSTENET (0,34=80/mn) ; t=E9l : 08 92 68 13 50 (0,34=80=
/mn)=0A=0A

Re: [Libexif-devel] Problems building libexif (multiple definitions of symbol)

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arthur Wiebe <ar...@gm...> writes:

> Making all in po
> make[2]: *** No rule to make target `all'.  Stop.
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> And help would be really appreciated.

AFAIR, OSX has FreeBSD userland, and FreeBSD has a history of gettext
problems.

If you can live without translated messages, add --disable-nls to the
./configure params.

Gru=C3=9F,

Uli
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBx/oN7nbUWdbN/BURAqpGAKCWFH2LPJ6KPNjV0lXLcD3ycX+gMgCfY1rY
qEceIPwOsNZ8qrh5zG9oqPw=3D
=3DI9wg
=2D----END PGP SIGNATURE-----

[Libexif-devel] Re: Status of french translation

[Arnaud L. <as...@la...>]

Le Fri, Dec 17, 2004 at 02:49:59PM +0100, Lutz M=FCller a =E9crit:
> > I'd need to know some basic things : which tools are you using to per=
form=20
> > translation (kbabel ?), do you have any checker tool, does it exist a=
=20
> > translation manager ? and any other information you can think of.
> The last translation has been done by Arnaud Launay <as...@la...>.
> Perhaps he can give you some pointers.

I used vim and the gettext tools, nothing more. Colin Marquart is
theoretically the general translation manager, but you can also
post it directly here.

	Arnaud.
--=20
http://launay.org/blog/
http://www.cusae.com/

Re: [Libexif-devel] Status of french translation

[Lutz <lu...@us...>]

On Fri, 2004-12-17 at 14:35 +0100, David Jobet wrote:
> Hello,
>=20
> I'd like to know the status of french translation of libexif and if I c=
an give=20
> some help.
>=20
> I'd need to know some basic things : which tools are you using to perfo=
rm=20
> translation (kbabel ?), do you have any checker tool, does it exist a=20
> translation manager ? and any other information you can think of.
>=20

The last translation has been done by Arnaud Launay <as...@la...>.
Perhaps he can give you some pointers.
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Status of french translation

[David J. <dav...@fr...>]

Hello,

I'd like to know the status of french translation of libexif and if I can give 
some help.

I'd need to know some basic things : which tools are you using to perform 
translation (kbabel ?), do you have any checker tool, does it exist a 
translation manager ? and any other information you can think of.

I'm currently contributing french translation to the digikam project (which is 
using libexif) and the last untranslated (or broken) strings come from 
libexif.

Kind regards

David
-- 
Nosica - http://www.nosica.net - natural language evolution