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

Re: [Libexif-devel] Re:sizeof(long) == 4?

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

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

> unless you equip libexif with definitions of uint16_t, uint32_t
> and int32_t, this "simple" change will break compilability for many
> platforms. E.g. MSVC does not know such types (is it in some latest C++
> standard?).

I have now added the macro from libgphoto2 which creates a _stdint.h
which should always contain adequate definitions for
u?int(8|16|32)_t.

I don't have MSVC, so could you please test it?

You can find a test tarball at

    http://n-dimensional.de/blaf/libexif-0.6.9.tar.gz
    http://n-dimensional.de/blaf/exif-0.6.9.tar.gz

[ test tarballs for the 0.7.0 release ]

BTW, how are you compiling libexif with MSVC? On unixoid systems, you
run

        ./configure
        make
        make install

On Windows, you don't have a shell to execute configure, so how do you
do that?

BTW, I managed to cross-compile the code from the tarball on a Debian
system for a W32 target using mingw32 using

      ./configure --host=3Di586-mingw32msvc

but I don't know how that helps you MSVC people, or how to create a
.DLL file. The result is just a libexif.a file.

Porting stuff to MSVC is new to me. I only have a little experience
with Cygwin and Mingw32 on W2K.

Gru=DF,

Uli

--=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] RE: libexif bug?

[Will R. <wi...@wi...>]

Thanks.
I've also forwarded a link to the bug to ofoto.
Hopefully they'll fix the bad exif data.
Actually, hopefully they'll stop their software from modifying the =
original images if all I am doing is uploading it to their site.

Will Rickards

-----Original Message-----
From: Hans Ulrich Niedermann [mailto:gp...@n-...]=20
Sent: Sunday, April 04, 2004 3:11 PM
To: Will Rickards
Cc: lib...@li...
Subject: Re: libexif bug?


"Will Rickards" <wi...@wi...> writes:

> Please see this bug I filed for the gimp jpeg plug-in.
> http://bugzilla.gnome.org/show_bug.cgi?id=3D138238
>
> It seems to have been tracked to libexif.
> Linux users report no problems but I'm using Windows XP SP1 or
> Windows 2K SP4.

That is probably the reason we didn't find that bug yet. None of us
developers have Windows machines that I know of.

So the general policy is that either you fix your Windows bugs and
send us patches, or you sponsor someone with a Windows box and
license.

However, in your case I also find a problem with the picture of your
son with gimp-2.0 under Linux:

Bogus marker length
Bogus marker length

And I cannot save the image if I want to save the EXIF data. So there
definitely is a problem your picture, and it also shows on Linux. So
we can do some testing.

> I was wondering if you could look into it or maybe ask one of the
> other developers to look into it?

Our mailing list is reachable at

        lib...@li...

Gru=DF,

Uli



__________ NOD32 1.704 (20040404) Information __________

This message was checked by NOD32 antivirus system.
http://www.nod32.com

Re: [Libexif-devel] Re: libexif bug?

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

On Sun, 2004-04-04 at 21:11, Hans Ulrich Niedermann wrote:
> "Will Rickards" <wi...@wi...> writes:
> 
> > Please see this bug I filed for the gimp jpeg plug-in.
> > http://bugzilla.gnome.org/show_bug.cgi?id=138238
> >
> > It seems to have been tracked to libexif.
> > Linux users report no problems but I'm using Windows XP SP1 or
> > Windows 2K SP4.

The program that you use to post-process your images writes strange
EXIF-data that seems to crash some versions of libexif. The CVS version
has sanity checks that prevent this crash. 

After a new version of libexif (and the gimp) has been released, you
will be able to process your images again.

Re: [Libexif-devel] new packages

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

On Sun, 2004-04-04 at 20:52, Hans Ulrich Niedermann wrote:
> So should we just release
> 
>    libexif 0.7.0
>    exif 0.7.0 depending on libexif >= 0.7.0

Sounds good for me.

Lutz

[Libexif-devel] Re: libexif bug?

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

"Will Rickards" <wi...@wi...> writes:

> Please see this bug I filed for the gimp jpeg plug-in.
> http://bugzilla.gnome.org/show_bug.cgi?id=3D138238
>
> It seems to have been tracked to libexif.
> Linux users report no problems but I'm using Windows XP SP1 or
> Windows 2K SP4.

That is probably the reason we didn't find that bug yet. None of us
developers have Windows machines that I know of.

So the general policy is that either you fix your Windows bugs and
send us patches, or you sponsor someone with a Windows box and
license.

However, in your case I also find a problem with the picture of your
son with gimp-2.0 under Linux:

Bogus marker length
Bogus marker length

And I cannot save the image if I want to save the EXIF data. So there
definitely is a problem your picture, and it also shows on Linux. So
we can do some testing.

> I was wondering if you could look into it or maybe ask one of the
> other developers to look into it?

Our mailing list is reachable at

        lib...@li...

Gru=DF,

Uli

Re: [Libexif-devel] new packages

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

Lutz M=FCller <lu...@us...> writes:

> Has anyone time to package current cvs ('make dist' or better 'make
> distcheck')?

OK, while I was trying that, I've found that in HEAD, configure.in
says that

  libexif is 0.5.12
  exif is 0.6
    and depends on libexif >=3D 0.5.13

There are no CVS tags which reflect the last few release tarballs. :-(
So I cannot quite figure out the rationale behind those version
numbers.

So should we just release

   libexif 0.7.0
   exif 0.7.0 depending on libexif >=3D 0.7.0

?

Gru=DF,

Uli

--=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

Re: [Libexif-devel] new packages

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

Lutz M=FCller <lu...@us...> writes:

> Has anyone time to package current cvs ('make dist' or better 'make
> distcheck')?

Good idea.

Then we can migrate the gphoto2 stuff to the new libexif as well and
do gphoto2 release...

I'm off compiling...

Uli

--=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] new packages

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

Hello!

Has anyone time to package current cvs ('make dist' or better 'make
distcheck')?
--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Re:sizeof(long) == 4?

[Joerg H. <jo...@de...>]

Hi

On Fri, Mar 19, 2004 at 06:48:10PM +0100, matthieu castet wrote:

> you could add something like that for those broken compilers (from 
> ffmpeg libavcodec/common.h)
> #ifndef EMULATE_INTTYPES
> #   include <inttypes.h>
> #else
>    typedef signed char  int8_t;
>    typedef signed short int16_t;
>    typedef signed int   int32_t;
>    typedef unsigned char  uint8_t;
>    typedef unsigned short uint16_t;
>    typedef unsigned int   uint32_t;
> 
> #   ifdef CONFIG_WIN32
>        typedef signed __int64   int64_t;
>        typedef unsigned __int64 uint64_t;
> #   else /* other OS */
>        typedef signed long long   int64_t;
>        typedef unsigned long long uint64_t;
> #   endif /* other OS */
> #endif /* HAVE_INTTYPES_H */

I've done the small solution for the moment; I include inttypes.h if its
available, otherwise I use the old code.

This introduces some warnings in printf-Statements, because I haven't found
the respective modifiers for uint32_t... Is there a possibility to fix
this?

Joerg

-- 
Fachbegriffe der Informatik (Nr 177): Mainframe-Admin
- Arbeitsschutzschuhe 
	Holger Spielmann

Re: [Libexif-devel] Re:sizeof(long) == 4?

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

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

> unless you equip libexif with definitions of uint16_t, uint32_t
> and int32_t, this "simple" change will break compilability for many
> platforms. E.g. MSVC does not know such types (is it in some latest C++
> standard?).

We should be able to copy that from libgphoto2. Including the autoconf
magic.

Gru=DF,

Uli

--=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

Re: [Libexif-devel] Re:sizeof(long) == 4?

[matthieu c. <cas...@fr...>]

Jan Patera wrote:

>Joerg,
>
>unless you equip libexif with definitions of uint16_t, uint32_t
>and int32_t, this "simple" change will break compilability for many
>platforms. E.g. MSVC does not know such types (is it in some latest C++
>standard?).
>
> --- Jan
>
>  
>
>>On Thu, Mar 18, 2004 at 03:45:52PM +0100, Hans Ulrich Niedermann wrote:
>>    
>>
>>>Definitely. For formats of a fixed size, one should always use
>>>u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake
>>>and #ifdef magic.
>>>      
>>>
>>I've looked into exif-utils.h and did small changes to:
>>
>>typedef char            ExifByte;          /* 1 byte  */
>>typedef char *          ExifAscii;
>>typedef uint16_t        ExifShort;         /* 2 bytes */
>>typedef uint32_t        ExifLong;          /* 4 bytes */
>>typedef struct {ExifLong numerator; ExifLong denominator;} ExifRational;
>>typedef char            ExifUndefined;     /* 1 byte  */
>>typedef int32_t         ExifSLong;         /* 4 bytes */
>>typedef struct {ExifSLong numerator; ExifSLong denominator;}
>>ExifSRational;
>>
>>
>>Now, all problems should disappear. Only some printf-Statements, which
>>need format modifier for eg ExifLong, are throwing warnings. Are there
>>any specifier for uint32_t which can be used with printf and friends?
>>
>>Joerg
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Libexif-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libexif-devel
>
>
>  
>
you could add something like that for those broken compilers (from 
ffmpeg libavcodec/common.h)
#ifndef EMULATE_INTTYPES
#   include <inttypes.h>
#else
    typedef signed char  int8_t;
    typedef signed short int16_t;
    typedef signed int   int32_t;
    typedef unsigned char  uint8_t;
    typedef unsigned short uint16_t;
    typedef unsigned int   uint32_t;

#   ifdef CONFIG_WIN32
        typedef signed __int64   int64_t;
        typedef unsigned __int64 uint64_t;
#   else /* other OS */
        typedef signed long long   int64_t;
        typedef unsigned long long uint64_t;
#   endif /* other OS */
#endif /* HAVE_INTTYPES_H */

Re: [Libexif-devel] Re:sizeof(long) == 4?

[Joerg H. <jo...@de...>]

On Fri, Mar 19, 2004 at 04:54:43PM +0100, Jan Patera wrote:
> Joerg,
> 
> unless you equip libexif with definitions of uint16_t, uint32_t
> and int32_t, this "simple" change will break compilability for many
> platforms. E.g. MSVC does not know such types (is it in some latest C++
> standard?).

Hm, where are my bookmarks? ...

http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf

page 28 (37 in the pdf) says "C9X also allows extended integer types (see
§7.8..."

In paragraph 7.8 "the purpose of <inittypes.h> is to provide a set of
integer types whose definitions are consistent across machines and
independent of operating systems and other implementation
idiosyncarsies..."

It seems to me that this is a part of C99 and therefor all modern C
compilers should implement it. I don't know, if VC is compatible with C99.

Joerg

-- 
Fachbegriffe der Informatik (Nr 203): Öffentliche Adressverzeichnisse
- Spammers Umschreibung für das Usenet. 
	Marc Haber

[Libexif-devel] Re:sizeof(long) == 4?

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

Joerg,

unless you equip libexif with definitions of uint16_t, uint32_t
and int32_t, this "simple" change will break compilability for many
platforms. E.g. MSVC does not know such types (is it in some latest C++
standard?).

 --- Jan

> On Thu, Mar 18, 2004 at 03:45:52PM +0100, Hans Ulrich Niedermann wrote:
> >
> > Definitely. For formats of a fixed size, one should always use
> > u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake
> > and #ifdef magic.
>
> I've looked into exif-utils.h and did small changes to:
>
> typedef char            ExifByte;          /* 1 byte  */
> typedef char *          ExifAscii;
> typedef uint16_t        ExifShort;         /* 2 bytes */
> typedef uint32_t        ExifLong;          /* 4 bytes */
> typedef struct {ExifLong numerator; ExifLong denominator;} ExifRational;
> typedef char            ExifUndefined;     /* 1 byte  */
> typedef int32_t         ExifSLong;         /* 4 bytes */
> typedef struct {ExifSLong numerator; ExifSLong denominator;}
> ExifSRational;
>
>
> Now, all problems should disappear. Only some printf-Statements, which
> need format modifier for eg ExifLong, are throwing warnings. Are there
> any specifier for uint32_t which can be used with printf and friends?
>
> Joerg

Re: [Libexif-devel] sizeof(long) == 4?

[Joerg H. <jo...@de...>]

Tach Hans Ulrich

On Thu, Mar 18, 2004 at 03:45:52PM +0100, Hans Ulrich Niedermann wrote:
> 
> Definitely. For formats of a fixed size, one should always use
> u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake
> and #ifdef magic.

I've looked into exif-utils.h and did small changes to:

typedef char            ExifByte;          /* 1 byte  */
typedef char *          ExifAscii;
typedef uint16_t        ExifShort;         /* 2 bytes */
typedef uint32_t        ExifLong;          /* 4 bytes */
typedef struct {ExifLong numerator; ExifLong denominator;} ExifRational;
typedef char            ExifUndefined;     /* 1 byte  */
typedef int32_t         ExifSLong;         /* 4 bytes */
typedef struct {ExifSLong numerator; ExifSLong denominator;} ExifSRational;


Now, all problems should disappear. Only some printf-Statements, which need
format modifier for eg ExifLong, are throwing warnings. Are there any
specifier for uint32_t which can be used with printf and friends?

Joerg

Re: [Libexif-devel] sizeof(long) == 4?

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

Hi Joerg :-)

Joerg Hoh <jo...@de...> writes:

> I've seen in several files unter libexif/, that sizeof(long) is assumed to
> be 4 bytes. On all 32bit plattforms this is true, but on linux and 64bit
> plattforms (x86-64, alpha, sparc64, ...) it is 8 bytes in size.
>
> I'll try to convert to that to uint32_t, which is always 32 bits in size.
> Maybe all references to exif_get_short to exif_get_uint16, too? This would
> be the most portable and consequent way to do this.

Definitely. For formats of a fixed size, one should always use
u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake
and #ifdef magic.

Gru=DF,

Uli

--=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] sizeof(long) == 4?

[Joerg H. <jo...@de...>]

Hi

I've seen in several files unter libexif/, that sizeof(long) is assumed to
be 4 bytes. On all 32bit plattforms this is true, but on linux and 64bit
plattforms (x86-64, alpha, sparc64, ...) it is 8 bytes in size.

I'll try to convert to that to uint32_t, which is always 32 bits in size.
Maybe all references to exif_get_short to exif_get_uint16, too? This would
be the most portable and consequent way to do this.

Joerg

-- 
Fachbegriffe der Informatik (Nr 313): Next Generation Ada
- Ada'Succ(s). 
	Derek Mahony

[Libexif-devel] RE: Bugfix for exif/exif/main.c

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

Hi,

Thanks for finding this bug! It is now in CVS.

 --- Jan

> exif kept on dumping core on me, so I decided to go searching for the
> culprit and here it is (BTW: valgrind really rocks):
> Index: exif/main.c
> RCS file: /cvsroot/libexif/exif/exif/main.c,v
> retrieving revision 1.37
> diff -u -r1.37 main.c
> --- exif/main.c 30 Sep 2003 22:43:00 -0000      1.37
> +++ exif/main.c 28 Jan 2004 20:35:27 -0000
> @@ -109,7 +109,7 @@
>          */
>          if (e->format == EXIF_FORMAT_ASCII) {
>                 if (e->data) free (e->data);
> -               e->components = strlen (e->data) + 1;
> +               e->components = strlen (set_value) + 1;
>                 e->size = strlen (set_value) + 1;
>                 e->data = malloc (sizeof (char) * e->size);
>                  if (!e->data) {
>
> What a trivial bug, but so hard to find.
>
> And before I forget: Thanks for libexif.
>
> Ah, and another remark: sizeof (char) =3D=3D 1. Always. Thats guaranteed
> by the standard. That libexif (and most probably 90% of the existing
> software which reads/writes binary data from/to files etc.) would stop
> working with a char size of more then 8 bit is quite obvious.

[Libexif-devel] Bugfix for exif/exif/main.c

[Sebastian W. <se...@se...>]

Hi,

exif kept on dumping core on me, so I decided to go searching for the
culprit and here it is (BTW: valgrind really rocks):

Index: exif/main.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/exif/exif/main.c,v
retrieving revision 1.37
diff -u -r1.37 main.c
--- exif/main.c 30 Sep 2003 22:43:00 -0000      1.37
+++ exif/main.c 28 Jan 2004 20:35:27 -0000
@@ -109,7 +109,7 @@
         */
         if (e->format =3D=3D EXIF_FORMAT_ASCII) {
                if (e->data) free (e->data);
-               e->components =3D strlen (e->data) + 1;
+               e->components =3D strlen (set_value) + 1;
                e->size =3D strlen (set_value) + 1;
                e->data =3D malloc (sizeof (char) * e->size);
                 if (!e->data) {

What a trivial bug, but so hard to find.

And before I forget: Thanks for libexif.

Ah, and another remark: sizeof (char) =3D=3D 1. Always. Thats guaranteed by
the standard. That libexif (and most probably 90% of the existing
software which reads/writes binary data from/to files etc.) would stop
working with a char size of more then 8 bit is quite obvious.

Bye,
Sebastian
--=20
Sebastian Wilhelmi                 |            h=E4r ovanf=F6r alla molnen
mailto:se...@se...              |     =E4r himmlen s=E5 f=F6runderligt b=
l=E5
http://seppi.de                    |

Re: [Libexif-devel] Re: Documentation

[Joe C. <jo...@cr...>]

Maybe,=20

 Assuming I get as far as using it, I will document it and give you the=20
patches. That is assumiung I dont either compromise or find a quicker way t=
o=20
skjin the cat in the mean time. I do know that the functionality I had in=20
mind for my program is now put on the back burner and I'm moving on to more=
=20
core items.

 When a person only has 30mins to an hour each day to work on a pet project=
,=20
things like no documentation make it all the harder to get it done. If I kn=
ow=20
the toolkit, in otherwords I helped write it, It would only take a few hour=
s=20
to create a quick document.

=2Djoe



On Monday 12 January 2004 06:42 am, Arnaud Launay wrote:
> Le Mon, Jan 12, 2004 at 06:21:50AM -0600, Joe Croft a =E9crit:
> >  For thos of us who don't have the 3 - 5 hours decipering other peoples
> > code, some man pages with short descriptions of the function all and su=
ch
> > would be real handy to go along with that as well. It would also go alo=
ng
> > ways to making your package complete.
>
> Fine with us, send us patches.
>
> 	Arnaud.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Libexif-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel

[Libexif-devel] Re: Documentation

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

Le Mon, Jan 12, 2004 at 06:21:50AM -0600, Joe Croft a =E9crit:
>  For thos of us who don't have the 3 - 5 hours decipering other peoples=
 code,=20
> some man pages with short descriptions of the function all and such wou=
ld be=20
> real handy to go along with that as well. It would also go along ways t=
o=20
> making your package complete.

Fine with us, send us patches.

	Arnaud.

Re: [Libexif-devel] Documentation

[Joe C. <jo...@cr...>]

Well,=20

 For thos of us who don't have the 3 - 5 hours decipering other peoples cod=
e,=20
some man pages with short descriptions of the function all and such would b=
e=20
real handy to go along with that as well. It would also go along ways to=20
making your package complete.

=2Djoe

On Monday 12 January 2004 01:56 am, Lutz M=FCller wrote:
> On Sun, 2004-01-11 at 23:38, Joe Croft wrote:
> > Hi Yall,
> >
> >  Where can one find documentation on how to use the exif library?
>
> We've got the header files, the test programs in libexif/test, and the
> source code of programs using libexif (like exif).
>
> Regards

Re: [Libexif-devel] Documentation

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

On Sun, 2004-01-11 at 23:38, Joe Croft wrote:
> Hi Yall,
>=20
>  Where can one find documentation on how to use the exif library?=20

We've got the header files, the test programs in libexif/test, and the
source code of programs using libexif (like exif).

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

[Libexif-devel] Documentation

[Joe C. <jo...@cr...>]

Hi Yall,

 Where can one find documentation on how to use the exif library? 

-joe

Re: [Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-content.h,1.7,1.8 exif-data.c,1.34,1.35 exif-entry.c,1.42,1.43 exif-entry.h,1.8,1.9 exif-mnote-data-priv.h,1.3,1.4 exif-mnote-data.c,1.3,1.4 exif-mnote-data.h,1.1,1.2

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

On Sat, 2004-01-10 at 21:52, Hans Ulrich Niedermann wrote:
> This breaks both source and binary compatibility.
>=20
> Is that wanted?

We thought it is worth it. Many people (especially in the windows world)
ship libexif together with their programs, therefore there aren't any
dependency problems there. In the linux world, we've got version numbers
to guard against linking problems.

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

[Libexif-devel] Re: [libexif-cvs] libexif/libexif exif-content.h,1.7,1.8 exif-data.c,1.34,1.35 exif-entry.c,1.42,1.43 exif-entry.h,1.8,1.9 exif-mnote-data-priv.h,1.3,1.4 exif-mnote-data.c,1.3,1.4 exif-mnote-data.h,1.1,1.2

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

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

> Update of /cvsroot/libexif/libexif/libexif
> In directory sc8-pr-cvs1:/tmp/cvs-serv29825
>
> Modified Files:
> 	exif-content.h exif-data.c exif-entry.c exif-entry.h 
> 	exif-mnote-data-priv.h exif-mnote-data.c exif-mnote-data.h 
> Log Message:
> 1) Two new arguments (char *val, unsinged int maxlen) added to the
> following functions and macros:
> exif_entry_get_value
> exif_entry_get_value_brief
> exif_mnote_data_get_value
> exif_mnote_data_pentax_get_value
> macros:
> exif_content_get_value
> exif_content_get_value_brief
>
> The functions return either NULL (in case of error) or val.

This breaks both source and binary compatibility.

Is that wanted?

Uli