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

[Libexif-devel] Re: libexif library soname change

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

On Fri, 2005-04-15 at 21:13 +0200, Hongli Lai wrote:
> Ok, so the problem is that you don't understand libtool versioning=20
> correctly. You should read 'info libtool' -> section Versioning.

I guess reading the small documentation in libexif/configure.in should
be sufficient for the average developer especially now that you have
corrected it:

> I attached a one-liner patch which fixes the=20
> comments.

Applied. Thanks!

> Is libexif 0.5.12 fully binary compatible with the latest libexif? I=20
> mean: if a program is compiled against libexif 0.5.12, and I rename=20
> libexif 0.6's library name to the name used by libexif 0.5.12, will tha=
t=20
> program still work?

No. I quickly read through libexif/ChangeLog and now remember 1 change
that we did between 5.11 (2003/08) and 6.9 (2004/05):=20

2004-01-07  Jan Patera <pa...@us...>

        Thread-safety, elimination of static variables, fixes of memory
        corruption (writing beyond provided space), no more memory leaks
        in mnote, 2 new args of exif_entry_get_value,

That is, a new required parameter has been added to the function
exif_entry_get_value. But that should be the only change since 5.12.

Please forgive me my ignorance, but I never even think about manually
linking programs or replacing old libraries with new ones manually.
"./autogen.sh && make install" usually does everything for me (including
checks for compatibility).

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

[Libexif-devel] Re: libexif library soname change

[Hongli L. <h....@ch...>]

Lutz Müller wrote:
> or that no-one has educated libexif developers (specifically me)
> sufficiently on how to correctly set up and maintain
> libexif/configure.in.
> 
> My goal up to now was to make sure that we don't release different
> incompatible versions of libexif with the same major version. It seems
> that I've fully reached that goal :-)
> 
> If I remember correctly, the last change breaking binary compatibility
> happened in July 2002. After that, we only added interfaces and fixed
> the code behind the existing API. 
> 
> There is some logic and documentation in libexif/configure.in that is
> probably incorrect or (at least) not clear enough. Up to now, if I added
> an interface, I just increased 'CURRENT'. See code snippet below. Could
> you send us a patch?
> 
> Thanks a lot!
> 
> Regards
> 
> Lutz
> 
> 
> dnl
> ---------------------------------------------------------------------------
> dnl Versioning:
> dnl  - AGE (Micro):      Increment if any interfaces have been added;
> set to 0
> dnl                      if any interfaces have been removed. Removal
> has
> dnl                      precedence over adding, so set to 0 if both
> happened.
> dnl  - REVISION (Minor): Increment any time the source changes; set to
> dnl                      0 if you incremented CURRENT.
> dnl  - CURRENT (Major):  Increment if the interface has additions,
> changes,
> dnl                      removals.
> dnl
> ---------------------------------------------------------------------------
> LIBEXIF_AGE=0
> LIBEXIF_REVISION=0
> LIBEXIF_CURRENT=12
> AC_SUBST([LIBEXIF_AGE])
> AC_SUBST([LIBEXIF_REVISION])
> AC_SUBST([LIBEXIF_CURRENT])
> LIBEXIF_VERSION_INFO=`expr $LIBEXIF_CURRENT + $LIBEXIF_REVISION`:
> $LIBEXIF_AGE:$LIBEXIF_REVISION
> AC_SUBST([LIBEXIF_VERSION_INFO])

Ok, so the problem is that you don't understand libtool versioning 
correctly. You should read 'info libtool' -> section Versioning.

If you add an interface, and don't change anything in the old interfaces 
which could break applications (this includes function semantics), then 
you are supposed to increase AGE, not CURRENT. So the comment is wrong 
too. Only if you did something that breaks binary compatibility, AGE 
should incremented. I attached a one-liner patch which fixes the 
comments. I won't touch the numbers because the damage has already been 
done. :(

Is libexif 0.5.12 fully binary compatible with the latest libexif? I 
mean: if a program is compiled against libexif 0.5.12, and I rename 
libexif 0.6's library name to the name used by libexif 0.5.12, will that 
program still work? And when was version 0.5.12 released?

[Libexif-devel] Re: libexif library soname change

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

On Fri, 2005-04-15 at 19:28 +0200, Hongli Lai wrote:
> Hi. I'm building an autopackage[1] for Gimp, and I came across a problem 
> with libexif: the library major has changed compared to the one shipped 
> with slightly older distributions, such as Fedora Core 1. This means 
> that libexif broke compatibility.

or that no-one has educated libexif developers (specifically me)
sufficiently on how to correctly set up and maintain
libexif/configure.in.

My goal up to now was to make sure that we don't release different
incompatible versions of libexif with the same major version. It seems
that I've fully reached that goal :-)

If I remember correctly, the last change breaking binary compatibility
happened in July 2002. After that, we only added interfaces and fixed
the code behind the existing API. 

There is some logic and documentation in libexif/configure.in that is
probably incorrect or (at least) not clear enough. Up to now, if I added
an interface, I just increased 'CURRENT'. See code snippet below. Could
you send us a patch?

Thanks a lot!

Regards

Lutz


dnl
---------------------------------------------------------------------------
dnl Versioning:
dnl  - AGE (Micro):      Increment if any interfaces have been added;
set to 0
dnl                      if any interfaces have been removed. Removal
has
dnl                      precedence over adding, so set to 0 if both
happened.
dnl  - REVISION (Minor): Increment any time the source changes; set to
dnl                      0 if you incremented CURRENT.
dnl  - CURRENT (Major):  Increment if the interface has additions,
changes,
dnl                      removals.
dnl
---------------------------------------------------------------------------
LIBEXIF_AGE=0
LIBEXIF_REVISION=0
LIBEXIF_CURRENT=12
AC_SUBST([LIBEXIF_AGE])
AC_SUBST([LIBEXIF_REVISION])
AC_SUBST([LIBEXIF_CURRENT])
LIBEXIF_VERSION_INFO=`expr $LIBEXIF_CURRENT + $LIBEXIF_REVISION`:
$LIBEXIF_AGE:$LIBEXIF_REVISION
AC_SUBST([LIBEXIF_VERSION_INFO])

Re: [Libexif-devel] Error handling: proposal

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

DEBUG:
 - DATA
 - MESSAGE

WARNING:
 - UNKNOWN_TAG
 - BAD_FORMAT

ERROR:
 - NO_MEMORY
 - DATA_AGAINST_SPECIFICATION
 - TOO_FEW_DATA
 - NO_EXIF_DATA
 - BAD_PARAMETER
 - FILE_NOT_FOUND
 - FILE_NOT_READABLE

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

Re: [Libexif-devel] Error handling

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

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

> On Tue, 2005-04-05 at 00:15 +0200, Hans Ulrich Niedermann wrote:
>> BTW, is anybody against me adding gtk-doc build stuff to libexif so
>> that people with gtk-doc and willing to invest a few CPU cycles can
>> build API docs?
>
> Why not. It's a bit overkill as there are no gtk-objects, signals and so
> on, but it should be better than nothing.

The alternative would be doxygen. I have to reacquaint me with both,
so I'm not biased.

I just thought as we were using gtk-doc for libgphoto2, we could use
it here as well.

Ideally, the comment markup format would be the same and we could use
both.

Uli

Re: [Libexif-devel] Error handling: proposal

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

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

> On Mon, 2005-04-04 at 23:24 +0200, Jan Patera wrote:
>> To the complexity: I was originally thinking about upto 10 status
>> codes, now my estimate is 10-15.
>
> Let's get down to business: Could you assemble this list? We can discuss
> the prefix (EXIF_RESULT or EXIF_LOG_CODE, whatever) later.
>
> DEBUG:
>  - DATA
>  - MESSAGE
>
> WARNING:
>  - UNKNOWN_TAG
>  - BAD_FORMAT
>
> ERROR:
>  - NO_MEMORY
>  - DATA_AGAINST_SPECIFICATION
>  - TOO_FEW_DATA
>  - NO_EXIF_DATA
>  - BAD_PARAMETER
   - FILE_NOT_FOUND

Re: [Libexif-devel] Error handling

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

On Tue, 2005-04-05 at 00:15 +0200, Hans Ulrich Niedermann wrote:
> BTW, is anybody against me adding gtk-doc build stuff to libexif so
> that people with gtk-doc and willing to invest a few CPU cycles can
> build API docs?

Why not. It's a bit overkill as there are no gtk-objects, signals and so
on, but it should be better than nothing.

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

Re: [Libexif-devel] Error handling: proposal

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

On Mon, 2005-04-04 at 23:24 +0200, Jan Patera wrote:
> To the complexity: I was originally thinking about upto 10 status
> codes, now my estimate is 10-15.

Let's get down to business: Could you assemble this list? We can discuss
the prefix (EXIF_RESULT or EXIF_LOG_CODE, whatever) later.

DEBUG:
 - DATA
 - MESSAGE

WARNING:
 - UNKNOWN_TAG
 - BAD_FORMAT

ERROR:
 - NO_MEMORY
 - DATA_AGAINST_SPECIFICATION
 - TOO_FEW_DATA
 - NO_EXIF_DATA
 - BAD_PARAMETER

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

Re: [Libexif-devel] Error handling

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

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

> thanks for your contribution to the discussion - I hope more & more
> people will join us. LibExif is small library although quite complex.
> I'd like to avoid blowing it up with complicated stacks or tables of
> error handlers.

Ack. Things are complicated enough as they are. If you want easy error
handling, use an exception capable language :-)

I think Mike just wants to design a little part of the API so he
has a starting point for documenting it :)

BTW, is anybody against me adding gtk-doc build stuff to libexif so
that people with gtk-doc and willing to invest a few CPU cycles can
build API docs?

Gru=C3=9F,

Uli

Re: [Libexif-devel] Error handling: proposal

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

>>> On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
>> I would return the first (or last - must be discussed) error of the
>> highest severity of all errors/warnings encountered.
>
> To summarize, exif-result.h would
>  - define 30+ error/warning codes (that must be discussed)
>  - define a hierarchy of those error codes (that must be discussed)
>
> Let me propose something different. It is up to the frontends to log
> messages and handle the queue (like now). Functions would return one or
> more of the following result codes:
>
> EXIF_RESULT_NONE =3D 0,
> EXIF_RESULT_DEBUG =3D 1 << 0,
> EXIF_RESULT_WARNING =3D 1 << 1,
> EXIF_RESULT_ERROR =3D 1 << 2
>
> That is: Only a couple of result codes. Few log codes. No hierarchy.

What about a compromise: Enlarging
typedef enum {
	EXIF_LOG_CODE_NONE,
	EXIF_LOG_CODE_DEBUG,
	EXIF_LOG_CODE_NO_MEMORY,
	EXIF_LOG_CODE_CORRUPT_DATA
} ExifLogCode;

to about 10 values: The logger will have information in machine readable
form and this from all invocations.

   --- Jan

Re: [Libexif-devel] Error handling

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

Hi,

thanks for your contribution to the discussion - I hope more & more
people will join us. LibExif is small library although quite complex.
I'd like to avoid blowing it up with complicated stacks or tables of
error handlers.

 -- Jan

>> Let's say we define EXIF_RESULT_OK, EXIF_RESULT_SOMEWHAT_OK and
>> EXIF_RESULT_NOT_OK. What code should libexif return if it encounters
>> an unknown tag or a wrong format on loading?
>
> I don't intend to suggest making things complex, but two options pop to
> mind that would clarify this:
>
> (1) Error handlers.
>
> Make an exif_set_handler(int error, void (*handler)(int err, char
> *msg)) or the like (my definition is just for example). Keep a table of
> error handlers. Set the default handler for every error to be the
> logging function currently in use. This makes EXIF_RESULT_SOMEWHAT_OK
> disambiguous, because by that point a developer will know what has
> happened, and it maintains compatibility with the current API, because
> by default, everything is still logged with the log handler.
>
> (2) Error stack.
>
> Make a simple struct that defines an error condition, and return a
> pointer to a stack of them. Yes, this means memory allocation, but it
> leaves it up to the developer as to what to do with it. Then it's just =
a
> matter of exif_errstack_cleanup(errstack *). This, however, leaves the
> current logging routines in an awkward limbo, where developers may
> develop around the stack, forget logging, and then, sometime down the
> road, someone will push for removing it from the API, because
> developers can already log things based on the error stack.
>
>
> I think that (1) is probably the best approach as (2) is horribly
> ugly, but I'm just throwing ideas out there. Let me know if I'm
> horribly off base.
>
> -- Mike "Dexter" Church
>
>
> -------------------------------------------------------
> 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

Re: [Libexif-devel] Error handling: proposal

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

Hi Uli & Lutz,

thanks a lot for summarization. Items 1. and 2. are exactly the
reasons for my proposal. Translation of log messages makes the
current situation evem more messy.
To the complexity: I was originally thinking about upto 10 status
codes, now my estimate is 10-15. I don't expect 30+ status codes.
As there are some fatal errors when LibEXIF gives up (fully
or partially - skipped rest of IFD) and some _warnings_ when LibEXIF
more or less continues (e.g. skipped {not fully interpreted} just 1 tag),
I am proposing structuring of the status codes for those who are interest=
ed.
I really want to avoid thread local storage, extra allocation,
stacks or other (complicated) tasks.
We are dealing with many corrupted files and buggy SW around, we need
reasonable error reporting.

 --- Jan

> Lutz M=C3=BCller <lu...@us...> writes:
>
>>>> On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
>>> I would return the first (or last - must be discussed) error of the
>>> highest severity of all errors/warnings encountered.
>>
>> To summarize, exif-result.h would
>>  - define 30+ error/warning codes (that must be discussed)
>>  - define a hierarchy of those error codes (that must be discussed)
>
> Sounds pretty complex to me.
>
>> I really doubt that programmers will implement checks for that many
>> error codes and get some useful information out of them. gnome-vfs for
>> example has exactly this problem.
>
>
>> Let me propose something different. It is up to the frontends to log
>> messages and handle the queue (like now). Functions would return one
>> or more of the following result codes:
>>
>> EXIF_RESULT_NONE =3D 0,
>> EXIF_RESULT_DEBUG =3D 1 << 0,
>> EXIF_RESULT_WARNING =3D 1 << 1,
>> EXIF_RESULT_ERROR =3D 1 << 2
>>
>> Frontends would do:
>>
>> res =3D exif_data_something ()
>> if (res & EXIF_RESULT_ERROR) {
>>   "Errors have occurred..." (show logged errors)
>>   if (res & EXIF_RESULT_DEBUG) {
>>     "Additional debugging information is available. Click here to show
>> it."
>>   }
>> } else if (res & EXIF_RESULT_WARNING) {
>>   StatusBar =3D "There have been problems executing the request. "
>>               (show logged warnings)
>>               "Click here to show more info."
>    if (res & EXIF_RESULT_DEBUG) {
>      "Additional debugging information is available. Click here to show
> it."
>    }
>> }
>>
>> That is: Only a couple of result codes. Few log codes. No hierarchy.
>>
>> How about that?
>
> Simple to implement in libexif.
>
> Simple to implement in a frontend, if the log functions are memory leak
> and buffer overflow safe.
>
> However, I see a potential problem:
>
> There may be cases when the frontend could react in a "sensible" way to
> certain kinds of errors, if it knew about the nature of the
> problem.
>
> The frontend needs more information in machine readable format, but tha=
t
> should be information relevant to the frontend.
>
> We have to keep in mind what we want to achive:
>
>   1. Frondends must know when a call to a libexif function failed.
>
>   2. The most simple way to transfer the information is its return
>      code, so it would be really nice if the frontend could do a
>      simple =3D=3D 0 or !=3D NULL comparison to find out whether the ca=
ll
> succeeded.
>
>      It is not coincidence that this is the standard way to do error
> reporting in C. :-)
>
>   3. There must be more detailed information for the user - the stuff
>      in the log messages. These are mostly translated, except perhaps
> for the lowest level debug info.
>
> Considering these three points, I'd suggest classic C library/POSIX
> return conventions, but with a slightly improved error reporting
> mechanism than a global "errno" variable (I don't think we want to deal
> with thread local storage).
>
> And the logging already goes a long way towards improvements. Of
> course, functions returning "int" can easily return a large number of
> different error codes, but with NULL pointers... I'm not sure ATM how t=
o
> do something similar here without resorting to a global error
> function... hmm... a callback function perhaps, like the logging?
>
> Uli

Re: [Libexif-devel] Error handling: proposal

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

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

>>> On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
>> I would return the first (or last - must be discussed) error of the
>> highest severity of all errors/warnings encountered.
>
> To summarize, exif-result.h would
>  - define 30+ error/warning codes (that must be discussed)
>  - define a hierarchy of those error codes (that must be discussed)

Sounds pretty complex to me.

> I really doubt that programmers will implement checks for that many error
> codes and get some useful information out of them. gnome-vfs for example
> has exactly this problem.


> Let me propose something different. It is up to the frontends to log
> messages and handle the queue (like now). Functions would return one or
> more of the following result codes:
>
> EXIF_RESULT_NONE =3D 0,
> EXIF_RESULT_DEBUG =3D 1 << 0,
> EXIF_RESULT_WARNING =3D 1 << 1,
> EXIF_RESULT_ERROR =3D 1 << 2
>
> Frontends would do:
>
> res =3D exif_data_something ()
> if (res & EXIF_RESULT_ERROR) {
>   "Errors have occurred..." (show logged errors)
>   if (res & EXIF_RESULT_DEBUG) {
>     "Additional debugging information is available. Click here to show it=
."
>   }
> } else if (res & EXIF_RESULT_WARNING) {
>   StatusBar =3D "There have been problems executing the request. "
>               (show logged warnings)
>               "Click here to show more info."
   if (res & EXIF_RESULT_DEBUG) {
     "Additional debugging information is available. Click here to show it."
   }
> }
>
> That is: Only a couple of result codes. Few log codes. No hierarchy.
>
> How about that?

Simple to implement in libexif.

Simple to implement in a frontend, if the log functions are memory
leak and buffer overflow safe.

However, I see a potential problem:

There may be cases when the frontend could react in a "sensible" way
to certain kinds of errors, if it knew about the nature of the
problem.

The frontend needs more information in machine readable format, but
that should be information relevant to the frontend.

We have to keep in mind what we want to achive:

  1. Frondends must know when a call to a libexif function failed.

  2. The most simple way to transfer the information is its return
     code, so it would be really nice if the frontend could do a
     simple =3D=3D 0 or !=3D NULL comparison to find out whether the call
     succeeded.

     It is not coincidence that this is the standard way to do error
     reporting in C. :-)

  3. There must be more detailed information for the user - the stuff
     in the log messages. These are mostly translated, except perhaps
     for the lowest level debug info.

Considering these three points, I'd suggest classic C library/POSIX
return conventions, but with a slightly improved error reporting
mechanism than a global "errno" variable (I don't think we want to
deal with thread local storage).

And the logging already goes a long way towards improvements. Of
course, functions returning "int" can easily return a large number of
different error codes, but with NULL pointers... I'm not sure ATM how
to do something similar here without resorting to a global error
function... hmm... a callback function perhaps, like the logging?

Uli

Re: [Libexif-devel] Error handling: proposal

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

>> On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
> I would return the first (or last - must be discussed) error of the
> highest severity of all errors/warnings encountered.

To summarize, exif-result.h would
 - define 30+ error/warning codes (that must be discussed)
 - define a hierarchy of those error codes (that must be discussed)

I really doubt that programmers will implement checks for that many error
codes and get some useful information out of them. gnome-vfs for example
has exactly this problem.

Let me propose something different. It is up to the frontends to log
messages and handle the queue (like now). Functions would return one or
more of the following result codes:

EXIF_RESULT_NONE =3D 0,
EXIF_RESULT_DEBUG =3D 1 << 0,
EXIF_RESULT_WARNING =3D 1 << 1,
EXIF_RESULT_ERROR =3D 1 << 2

Frontends would do:

res =3D exif_data_something ()
if (res & EXIF_RESULT_ERROR) {
  "Errors have occurred..." (show logged errors)
  if (res & EXIF_RESULT_DEBUG) {
    "Additional debugging information is available. Click here to show it=
."
  }
} else if (res & EXIF_RESULT_WARNING) {
  StatusBar =3D "There have been problems executing the request. "
              (show logged warnings)
              "Click here to show more info."
}

That is: Only a couple of result codes. Few log codes. No hierarchy.

How about that?

Lutz

Re: [Libexif-devel] Error handling: proposal

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

> On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
>> EXIF_RESULT_UNKNOWN_TAG and EXIF_RESULT_WRONG_TAG_FORMAT,
>
> Do I understand correctly that you wouldn't be able to return both
> EXIF_RESULT_UNKNOWN_TAG and EXIF_RESULT_WRONG_TAG_FORMAT together? Woul=
d
> you just return EXIF_RESULT_WARN and the first error code occurred?

I would return the first (or last - must be discussed) error of the
highest severity of all errors/warnings encountered.
Presently, the current code gives up parsing an IFD if an unknown tag
is encountered (unless in LIBMNOTE) which is not the case
when wrong tag format is encountered (via CF & CC macros).
Therefore EXIF_RESULT_UNKNOWN_TAG would be returned regardless
of the order.

The current code can encounter 2 non-100%OK codes
only if they are encountered in two different IFDs.

 --- Jan

Re: [Libexif-devel] Error handling: proposal

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

On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
> EXIF_RESULT_UNKNOWN_TAG and EXIF_RESULT_WRONG_TAG_FORMAT,

Do I understand correctly that you wouldn't be able to return both
EXIF_RESULT_UNKNOWN_TAG and EXIF_RESULT_WRONG_TAG_FORMAT together? Would
you just return EXIF_RESULT_WARN and the first error code occurred?

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

Re: [Libexif-devel] Error handling

[Poindexter F. <sli...@gm...>]

> Let's say we define EXIF_RESULT_OK, EXIF_RESULT_SOMEWHAT_OK and
> EXIF_RESULT_NOT_OK. What code should libexif return if it encounters an
> unknown tag or a wrong format on loading?

I don't intend to suggest making things complex, but two options pop
to mind that would clarify this:

(1) Error handlers.

Make an exif_set_handler(int error, void (*handler)(int err, char
*msg)) or the like (my definition is just for example). Keep a table
of error handlers. Set the default handler for every error to be the
logging function currently in use. This makes EXIF_RESULT_SOMEWHAT_OK
disambiguous, because by that point a developer will know what has
happened, and it maintains compatibility with the current API, because
by default, everything is still logged with the log handler.

(2) Error stack.

Make a simple struct that defines an error condition, and return a
pointer to a stack of them. Yes, this means memory allocation, but it
leaves it up to the developer as to what to do with it. Then it's just
a matter of exif_errstack_cleanup(errstack *). This, however, leaves
the current logging routines in an awkward limbo, where developers may
develop around the stack, forget logging, and then, sometime down the
road, someone will push for removing it from the API, because
developers can already log things based on the error stack.


I think that (1) is probably the best approach as (2) is horribly
ugly, but I'm just throwing ideas out there. Let me know if I'm
horribly off base.

-- Mike "Dexter" Church

Re: [Libexif-devel] Error handling: proposal

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

Hi Lutz,

> On Wed, 2005-03-30 at 19:23 +0200, Jan Patera wrote:
>> should I understand it as you are strictly against completion codes
>> returned by exif functions?
>
> No, not at all. All I wanted to do is to make people aware of the limit=
s
> of error codes.
>
> Let's say we define EXIF_RESULT_OK, EXIF_RESULT_SOMEWHAT_OK and
> EXIF_RESULT_NOT_OK. What code should libexif return if it encounters an
> unknown tag or a wrong format on loading?

EXIF_RESULT_UNKNOWN_TAG and EXIF_RESULT_WRONG_TAG_FORMAT,
EXIF_RESULT_WRONG_SOMETHING_FORMAT and
EXIF_RESULT_WRONG_SOMETHING_ELSE_FORMAT. Depending on the situation.
There would be as many values as needed.

The values could be like SCODE/HRESULT in COM and similar interfaces:
some bits would indicate success/warning/error and some bits
what actually happened. There would be macros for simple checks
if (fatal) error or warning occured.

//  Values are 32 bit values layed out as follows:
//
//   3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
//   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
//  +---+-+-+-----------------------+-------------------------------+
//  |Sev|   |     Facility          |               Code            |
//  +---+-+-+-----------------------+-------------------------------+
//
//  where
//      Sev - is the severity code
//          00 - Success
//          01 - Informational
//          10 - Warning
//          11 - Error
//      Facility - is the facility code
//      Code - is the facility's status code

#define EXIF_ERROR  0xC0000000
#define EXIF_WARN   0x80000000

Examples:
#define EXIF_FAILED(x)  (((x) & 0xC0000000) =3D=3D EXIF_ERROR) ? TRUE : F=
ALSE)
#define EXIF_ALMOST_OK(x) (((x) & 0xC0000000) =3D=3D EXIF_WARN) ? TRUE : =
FALSE)
#define EXIF_NO_MEMORY(x) (((x) & 0xFFFF) =3D=3D EXIF_CODE_NOMEMORY) ? TR=
UE :
FALSE)

// START of internal values
#define EXIF_CODE_NOMEMORY       1
#define EXIF_CODE_CANT_OPEN      2
#define EXIF_CODE_NO_DATA        3
#define EXIF_FAC_IFD      0x10000  // IFD parser
#define EXIF_FAC_LOADER   0x20000  // JPEG loader
#define EXIF_FAC_MNOTE    0x30000
// END of internal values

#define EX_MNOTE_NO_MEMORY   (EXIF_FAC_MNOTE | EXIF_EXIF_CODE_NOMEMORY)
#define EX_LOADER_NO_MEMORY  (EXIF_FAC_LOADER | EXIF_CODE_NOMEMORY)
#define EX_LOADER_NO_MEMORY_FATAL (EXIF_FAC_LOADER | EXIF_CODE_NOMEMORY |
EXIF_ERROR)
#define EX_CANNOT_OPEN_FILE  (EXIF_FAC_LOADER | EXIF_CODE_CANT_OPEN |
EXIF_ERROR)
#define EX_WRONG_TAG_FORMAT  (EXIF_WARN | EXIF_FAC_IFD |
EXIF_CODE_WRONG_FORMAT)
#define EX_WRONG_IFD_FORMAT  (EXIF_WARN | EXIF_FAC_LOADER |
EXIF_CODE_WRONG_FORMAT)
#define EX_WRONG_MNOTE_FORMAT (EXIF_WAR | EXIF_FAC_MNOTE |
EXIF_CODE_WRONG_FORMAT)
#define EX_NO_EXIF_DATA      (EXIF_WARN | EXIF_FAC_LOADER |
EXIF_CODE_NO_DATA)

Amd of course also this one ;-)
#define EX_OK     0

All relevant "returns;"'s would be replaced with appropriate
"return EX_CANNOT_OPEN_FILE;" or "return EX_WRONG_MNOTE_FORMAT;"

Quite powerfull bit-mask macros with mininum overhead in libEXIF
(just changed returns) giving lots of information.

 I hope you've got the idea ;-)
How do you (and also others) like it?

 --- Jan

Re: [Libexif-devel] Error handling

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

On Wed, 2005-03-30 at 19:23 +0200, Jan Patera wrote:
> should I understand it as you are strictly against completion codes
> returned by exif functions?

No, not at all. All I wanted to do is to make people aware of the limits
of error codes.

Let's say we define EXIF_RESULT_OK, EXIF_RESULT_SOMEWHAT_OK and
EXIF_RESULT_NOT_OK. What code should libexif return if it encounters an
unknown tag or a wrong format on loading?
--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Error handling

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

Hi Lutz,

should I understand it as you are strictly against completion codes
returned by exif functions?
With the current code, many error situations are not propagated.
(see also for example bug #1169213). Ambigious completion codes should
be commented like in the header file "part of tags may have been
successfully parsed. It is upto you (i.e. the programmer) if you discard
everything or use partial results of what has been parsed."
I am not calling for changed program logic. I am just proposing that
instead
if (! is_this_correct(x)) {
 exif_log(blabla);
 return;
}
the code should be like

if (! is_this_correct(x)) {
 exif_log(blabla);
 return EXIF_STATUS_X_IS_WRONG;
}

It is up the user of the library (I again mean the programmer)
if he decides to parse log are use the error codes.
As a programmer, I _much_ more prefer the error codes.
Which doesn't mean I don't like displaying the log messages.
I just want offer the user (or do automatically) just only the appropriat=
e
actions when something goes as not expected.

 -- Jan

> On Wed, 2005-03-30 at 11:25 +0200, Jan Patera wrote:
>> Lutz occasionally adds calls of exif_log() when something goes wrong.
>> Various error conditions can be determined by constants
>> like EXIF_LOG_CODE_CORRUPT_DATA.
>> The bad thing is that exif_log() is then followed by return;
>> because most functions return void.
>
> I wouldn't call this a bad thing. libexif has processed the request as
> far as possible (even when having encountered non-critical problems lik=
e
> unknown markers and so on). Everything (including errors) has been
> communicated to the frontend.
>
>> I believe it would be
>> much better if the functions returned some completion status, like 0
>> for success and non-zero values like EXIF_LOG_CODE_CORRUPT_DATA when
>> something goes wrong.
>
> It certainly would make programming much easier in some cases. But what
> do in case of multiple errors (like 2 unknown tags and 1 bad format but
> otherwise data ok)? I'd rather let frontends scan the log messages for
> errors. If there are categories missing (AGAINST_SPEC,
> NOT_ENOUGH_DATA...) we can just add them.
>
>> Besides corrupted data, it is currently nearly impossible e.g.
>> to see why no libexif data was obtained - it can be missing libExif
>> APP marker, no rights to the JPEG file or even suddently missing JPEG
>> file.
>
> libexif is about reading EXIF data. Handling above problems is not in
> the scope of libexif (IMHO). In my opinion, exif_data_new_from_file is
> just a quick&dirty convenience function. It works in most cases, but
> you'd better:
> exif_data_new_mm
> exif_data_log
> exif_data_load_data
>
>> The only way how to see what went wrong is actually kind of
>> asynchronous interception of results of exif_log invocations
>> and analysis of the results later
>
> Which is not so bad. That way, you've got all information instead of
> just a code.
> --
> Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Error handling

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

On Wed, 2005-03-30 at 11:25 +0200, Jan Patera wrote:
> Lutz occasionally adds calls of exif_log() when something goes wrong.
> Various error conditions can be determined by constants
> like EXIF_LOG_CODE_CORRUPT_DATA.=20
> The bad thing is that exif_log() is then followed by return;
> because most functions return void.=20

I wouldn't call this a bad thing. libexif has processed the request as
far as possible (even when having encountered non-critical problems like
unknown markers and so on). Everything (including errors) has been
communicated to the frontend.

> I believe it would be
> much better if the functions returned some completion status, like
> 0 for success and non-zero values like EXIF_LOG_CODE_CORRUPT_DATA when
> something goes wrong.

It certainly would make programming much easier in some cases. But what
do in case of multiple errors (like 2 unknown tags and 1 bad format but
otherwise data ok)? I'd rather let frontends scan the log messages for
errors. If there are categories missing (AGAINST_SPEC,
NOT_ENOUGH_DATA...) we can just add them.

> Besides corrupted data, it is currently nearly impossible e.g.
> to see why no libexif data was obtained - it can be missing libExif
> APP marker, no rights to the JPEG file or even suddently missing
> JPEG file.

libexif is about reading EXIF data. Handling above problems is not in
the scope of libexif (IMHO). In my opinion, exif_data_new_from_file is
just a quick&dirty convenience function. It works in most cases, but
you'd better:
exif_data_new_mm
exif_data_log
exif_data_load_data

> The only way how to see what went wrong is actually kind of
> asynchronous interception of results of exif_log invocations
> and analysis of the results later

Which is not so bad. That way, you've got all information instead of
just a code.=20
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Error handling

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

Hi Lutz and others,

I am thinking about reasonable error handling in libexif.
Lutz occasionally adds calls of exif_log() when something goes wrong.
Various error conditions can be determined by constants
like EXIF_LOG_CODE_CORRUPT_DATA. 
The bad thing is that exif_log() is then followed by return;
because most functions return void. I believe it would be
much better if the functions returned some completion status, like
0 for success and non-zero values like EXIF_LOG_CODE_CORRUPT_DATA when
something goes wrong.
Besides corrupted data, it is currently nearly impossible e.g.
to see why no libexif data was obtained - it can be missing libExif
APP marker, no rights to the JPEG file or even suddently missing
JPEG file.
The only way how to see what went wrong is actually kind of
asynchronous interception of results of exif_log invocations
and analysis of the results later


ed = exif_data_new_from_file(fileName);

if (ed == NULL) {
  analyze recorded exif_log information to see what failed.
  Most likely memory allocation problem _somewhere_
  return FAILURE;
}

// ed is not NULL. 3 scenarios possible:
// 1) evertyhing went OK
// 2) no appropriate APP marker
// 3) opening the file failed

  analyze recorded exif_log information to see if 1) is the case

Changing return code from void to some enum type wouldn't cause
any binary incompatibility issue - the code would be backward
binary compatible.

What do you think? This my proposal relates to bug #1054323
where Hans already mentioned this issue.

 --- Jan

[Libexif-devel] Intermittent outage of CVS commit notification mails

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

Hi,

a few commits by me (which should mostly be reverted by now :-)
weren't sent out by mail due to low disk space on the sf.net mail
server.

Just for the record, in case someone wonders :-)

Uli

[Libexif-devel] re: Request for test images

[Poindexter F. <sli...@gm...>]

Sorry Hans, but I just joined the list and unable to procure your
e-mail to send my test image to (browsing archives masks e-mail
addresses). Could you reply to me with it?

Thanks,

-- Dex

[Libexif-devel] gimp-2.2.4 compiled against libexif-0.6.12 crashes

[acrux <acr...@li...>]

hi all,

it seems that gimp-2.2.4 compiled against libexif-0.6.12 crashes when
try to open .jpg with exif datas.
No problem with the previuos libexif-0.6.11


greetz,
Acrux
--=20
vesuvio | LinuxMachine 156116
powered by GNU/Linux Crux
 # GnuPG/PGP Key_ID: 0x378EECB8