bug#7908: png-1.5 fix for emacs-23.2 and HEAD

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Thomas Klausner]

[-- Attachment #1: Type: text/plain, Size: 210 bytes --]

emacs-23.2 and git master from a few minutes don't compile against the
rather new png-1.5, which is hiding internal structure members.

The attached patch fixes the problem. Please include it.

Thanks,
 Thomas

[-- Attachment #2: patch-ae --]
[-- Type: text/plain, Size: 686 bytes --]

$NetBSD$

Fix build with png-1.5. 

--- src/image.c.orig	2011-01-16 17:00:54.000000000 +0900
+++ src/image.c	2011-01-16 17:04:35.000000000 +0900
@@ -5538,7 +5538,11 @@
   /* Avoid compiler warning about deprecated direct access to
      png_ptr's fields in libpng versions 1.4.x.  */
   image_error ("PNG error: %s", build_string (msg), Qnil);
+#if (PNG_LIBPNG_VER < 10500)
   longjmp (png_ptr->jmpbuf, 1);
+#else
+  png_longjmp (png_ptr, 1);
+#endif
 }
 
 
@@ -5700,7 +5704,7 @@
 
   /* Set error jump-back.  We come back here when the PNG library
      detects an error.  */
-  if (setjmp (png_ptr->jmpbuf))
+  if (setjmp (png_jmpbuf(png_ptr)))
     {
     error:
       if (png_ptr)

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> Date: Mon, 24 Jan 2011 13:54:37 +0100
> From: Thomas Klausner <tk@giga.or.at>
> Cc: 
> 
> emacs-23.2 and git master from a few minutes don't compile against the
> rather new png-1.5, which is hiding internal structure members.

"Doesn't compile" is a bit of exaggeration, I think: the members are
declared with `__attribute__((deprecated))', which produces warning
messages.

> The attached patch fixes the problem. Please include it.

Thanks, but this patch won't work with dynamic link against libpng, at
least not on MS-Windows, because the expansion of png_jmpbuf, viz.:

  #  define png_jmpbuf(png_ptr) \
     (*png_set_longjmp_fn((png_ptr), longjmp, sizeof (jmp_buf)))

causes link errors, since png_set_longjmp_fn is not available (a NULL
pointer) until the DLL is loaded.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Thomas Klausner]

On Mon, Jan 24, 2011 at 07:43:41PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 24 Jan 2011 13:54:37 +0100
> > From: Thomas Klausner <tk@giga.or.at>
> > Cc: 
> > 
> > emacs-23.2 and git master from a few minutes don't compile against the
> > rather new png-1.5, which is hiding internal structure members.
> 
> "Doesn't compile" is a bit of exaggeration, I think: the members are
> declared with `__attribute__((deprecated))', which produces warning
> messages.

That was true with png-1.4, but with png-1.5, it's incorrect.
emacs-23.2 compilation output with png-1.5 and without the patch:
image.c: In function 'my_png_error':
image.c:5651: error: dereferencing pointer to incomplete type
image.c: In function 'png_load':
image.c:5827: error: dereferencing pointer to incomplete type

> > The attached patch fixes the problem. Please include it.
> 
> Thanks, but this patch won't work with dynamic link against libpng, at
> least not on MS-Windows, because the expansion of png_jmpbuf, viz.:
> 
>   #  define png_jmpbuf(png_ptr) \
>      (*png_set_longjmp_fn((png_ptr), longjmp, sizeof (jmp_buf)))
> 
> causes link errors, since png_set_longjmp_fn is not available (a NULL
> pointer) until the DLL is loaded.

Ok, then you'll probably need something like
...
DEF_IMGLIB_FN (png_set_longjmp_fn);
...
LOAD_IMGLIB_FN (library, png_set_longjmp_fn);
...
#define fn_png_set_longjmp_fn	png_set_longjmp_fn
...
setjmp(*png_set_longjmp_fn(png_ptr, longjmp, sizeof(jmp_buf)));
...

and similarly for png_longjmp. Completely untested, just guessed,
since I haven't tried compiling emacs on MS-Windows before.

Hope this helps,
  Thomas

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> Date: Mon, 24 Jan 2011 22:59:40 +0100
> From: Thomas Klausner <tk@giga.or.at>
> Cc: 7908@debbugs.gnu.org
> 
> DEF_IMGLIB_FN (png_set_longjmp_fn);
> ...
> LOAD_IMGLIB_FN (library, png_set_longjmp_fn);
> ...
> #define fn_png_set_longjmp_fn	png_set_longjmp_fn
> ...
> setjmp(*png_set_longjmp_fn(png_ptr, longjmp, sizeof(jmp_buf)));
> ...
> 
> and similarly for png_longjmp. Completely untested, just guessed,
> since I haven't tried compiling emacs on MS-Windows before.

This doesn't work, I tried that a few weeks ago, and I still get link
errors.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Thomas Klausner]

On Tue, Jan 25, 2011 at 05:49:53AM +0200, Eli Zaretskii wrote:
> This doesn't work, I tried that a few weeks ago, and I still get link
> errors.

What are the errors?
 Thomas

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 08:18:48 +0100
> From: Thomas Klausner <tk@giga.or.at>
> Cc: 7908@debbugs.gnu.org
> 
> On Tue, Jan 25, 2011 at 05:49:53AM +0200, Eli Zaretskii wrote:
> > This doesn't work, I tried that a few weeks ago, and I still get link
> > errors.
> 
> What are the errors?

Unresolved external for the symbol of this function.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Thomas Klausner]

On Tue, Jan 25, 2011 at 05:53:08AM -0500, Eli Zaretskii wrote:
> > Date: Tue, 25 Jan 2011 08:18:48 +0100
> > From: Thomas Klausner <tk@giga.or.at>
> > Cc: 7908@debbugs.gnu.org
> > 
> > On Tue, Jan 25, 2011 at 05:49:53AM +0200, Eli Zaretskii wrote:
> > > This doesn't work, I tried that a few weeks ago, and I still get link
> > > errors.
> > 
> > What are the errors?
> 
> Unresolved external for the symbol of this function.

Sorry, can't help you with that then.
But the fact remains that emacs doesn't compile against png-1.5.
 Thomas

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> DEF_IMGLIB_FN (png_set_longjmp_fn);
>> LOAD_IMGLIB_FN (library, png_set_longjmp_fn);
>> #define fn_png_set_longjmp_fn	png_set_longjmp_fn
>> setjmp(*png_set_longjmp_fn(png_ptr, longjmp, sizeof(jmp_buf)));
>>
>> and similarly for png_longjmp. Completely untested, just guessed,
>> since I haven't tried compiling emacs on MS-Windows before.
>
> This doesn't work, I tried that a few weeks ago, and I still get link
> errors.

Do you have the exact link errors?  If possible, please try with this
patch (the libpng API changes are a bit of a mess, and it's possible
that small changes might affect success or failure).

*** src/image.c	2011-01-16 15:40:47 +0000
--- src/image.c	2011-01-25 20:57:03 +0000
***************
*** 5590,5595 ****
--- 5590,5600 ----
  DEF_IMGLIB_FN (png_read_end);
  DEF_IMGLIB_FN (png_error);
  
+ #if (PNG_LIBPNG_VER >= 10500)
+ DEF_IMGLIB_FN (png_longjmp);
+ DEF_IMGLIB_FN (png_set_longjmp_fn);
+ #endif /* libpng version >= 1.5 */
+ 
  static int
  init_png_functions (Lisp_Object libraries)
  {
***************
*** 5620,5625 ****
--- 5625,5636 ----
    LOAD_IMGLIB_FN (library, png_read_image);
    LOAD_IMGLIB_FN (library, png_read_end);
    LOAD_IMGLIB_FN (library, png_error);
+ 
+ #if (PNG_LIBPNG_VER >= 10500)
+   LOAD_IMGLIB_FN (library, png_longjmp);
+   LOAD_IMGLIB_FN (library, png_set_longjmp_fn);
+ #endif /* libpng version >= 1.5 */
+ 
    return 1;
  }
  #else
***************
*** 5646,5653 ****
--- 5657,5680 ----
  #define fn_png_read_end			png_read_end
  #define fn_png_error			png_error
  
+ #if (PNG_LIBPNG_VER >= 10500)
+ #define fn_png_longjmp			png_longjmp
+ #define fn_png_set_longjmp_fn		png_set_longjmp_fn
+ #endif /* libpng version >= 1.5 */
+ 
  #endif /* HAVE_NTGUI */
  
+ 
+ #if (PNG_LIBPNG_VER < 10500)
+ #define PNG_LONGJMP(ptr) (longjmp (ptr->jmpbuf, 1))
+ #define PNG_JMPBUF(ptr) ((ptr)->jmpbuf)
+ #else
+ /* In libpng version 1.5, the jmpbuf member is hidden.  */
+ #define PNG_LONGJMP(ptr) (fn_png_longjmp (png_ptr, 1))
+ #define PNG_JMPBUF(ptr) \
+   (*fn_png_set_longjmp_fn((ptr), longjmp, sizeof (jmp_buf)))
+ #endif
+ 
  /* Error and warning handlers installed when the PNG library
     is initialized.  */
  
***************
*** 5660,5666 ****
    /* Avoid compiler warning about deprecated direct access to
       png_ptr's fields in libpng versions 1.4.x.  */
    image_error ("PNG error: %s", build_string (msg), Qnil);
!   longjmp (png_ptr->jmpbuf, 1);
  }
  
  
--- 5687,5693 ----
    /* Avoid compiler warning about deprecated direct access to
       png_ptr's fields in libpng versions 1.4.x.  */
    image_error ("PNG error: %s", build_string (msg), Qnil);
!   PNG_LONGJMP (png_ptr);
  }
  
  
***************
*** 5836,5842 ****
  
    /* Set error jump-back.  We come back here when the PNG library
       detects an error.  */
!   if (setjmp (png_ptr->jmpbuf))
      {
      error:
        if (png_ptr)
--- 5863,5869 ----
  
    /* Set error jump-back.  We come back here when the PNG library
       detects an error.  */
!   if (PNG_JMPBUF (png_ptr))
      {
      error:
        if (png_ptr)

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>> This doesn't work, I tried that a few weeks ago, and I still get link
>> errors.
>
> Do you have the exact link errors?  If possible, please try with this
> patch (the libpng API changes are a bit of a mess, and it's possible
> that small changes might affect success or failure).

Sorry, there was a typo in the patch I sent, use this instead:

*** src/image.c	2011-01-16 15:40:47 +0000
--- src/image.c	2011-01-25 21:04:20 +0000
***************
*** 5590,5595 ****
--- 5590,5600 ----
  DEF_IMGLIB_FN (png_read_end);
  DEF_IMGLIB_FN (png_error);
  
+ #if (PNG_LIBPNG_VER >= 10500)
+ DEF_IMGLIB_FN (png_longjmp);
+ DEF_IMGLIB_FN (png_set_longjmp_fn);
+ #endif /* libpng version >= 1.5 */
+ 
  static int
  init_png_functions (Lisp_Object libraries)
  {
***************
*** 5620,5625 ****
--- 5625,5636 ----
    LOAD_IMGLIB_FN (library, png_read_image);
    LOAD_IMGLIB_FN (library, png_read_end);
    LOAD_IMGLIB_FN (library, png_error);
+ 
+ #if (PNG_LIBPNG_VER >= 10500)
+   LOAD_IMGLIB_FN (library, png_longjmp);
+   LOAD_IMGLIB_FN (library, png_set_longjmp_fn);
+ #endif /* libpng version >= 1.5 */
+ 
    return 1;
  }
  #else
***************
*** 5646,5653 ****
--- 5657,5680 ----
  #define fn_png_read_end			png_read_end
  #define fn_png_error			png_error
  
+ #if (PNG_LIBPNG_VER >= 10500)
+ #define fn_png_longjmp			png_longjmp
+ #define fn_png_set_longjmp_fn		png_set_longjmp_fn
+ #endif /* libpng version >= 1.5 */
+ 
  #endif /* HAVE_NTGUI */
  
+ 
+ #if (PNG_LIBPNG_VER < 10500)
+ #define PNG_LONGJMP(ptr) (longjmp (ptr->jmpbuf, 1))
+ #define PNG_JMPBUF(ptr) ((ptr)->jmpbuf)
+ #else
+ /* In libpng version 1.5, the jmpbuf member is hidden.  */
+ #define PNG_LONGJMP(ptr) (fn_png_longjmp (png_ptr, 1))
+ #define PNG_JMPBUF(ptr) \
+   (*fn_png_set_longjmp_fn((ptr), longjmp, sizeof (jmp_buf)))
+ #endif
+ 
  /* Error and warning handlers installed when the PNG library
     is initialized.  */
  
***************
*** 5660,5666 ****
    /* Avoid compiler warning about deprecated direct access to
       png_ptr's fields in libpng versions 1.4.x.  */
    image_error ("PNG error: %s", build_string (msg), Qnil);
!   longjmp (png_ptr->jmpbuf, 1);
  }
  
  
--- 5687,5693 ----
    /* Avoid compiler warning about deprecated direct access to
       png_ptr's fields in libpng versions 1.4.x.  */
    image_error ("PNG error: %s", build_string (msg), Qnil);
!   PNG_LONGJMP (png_ptr);
  }
  
  
***************
*** 5836,5842 ****
  
    /* Set error jump-back.  We come back here when the PNG library
       detects an error.  */
!   if (setjmp (png_ptr->jmpbuf))
      {
      error:
        if (png_ptr)
--- 5863,5869 ----
  
    /* Set error jump-back.  We come back here when the PNG library
       detects an error.  */
!   if (setjmp (PNG_JMPBUF (png_ptr)))
      {
      error:
        if (png_ptr)

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Thomas Klausner <tk@giga.or.at>, 7908@debbugs.gnu.org
> Date: Tue, 25 Jan 2011 15:57:38 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> DEF_IMGLIB_FN (png_set_longjmp_fn);
> >> LOAD_IMGLIB_FN (library, png_set_longjmp_fn);
> >> #define fn_png_set_longjmp_fn	png_set_longjmp_fn
> >> setjmp(*png_set_longjmp_fn(png_ptr, longjmp, sizeof(jmp_buf)));
> >>
> >> and similarly for png_longjmp. Completely untested, just guessed,
> >> since I haven't tried compiling emacs on MS-Windows before.
> >
> > This doesn't work, I tried that a few weeks ago, and I still get link
> > errors.
> 
> Do you have the exact link errors?  If possible, please try with this
> patch (the libpng API changes are a bit of a mess, and it's possible
> that small changes might affect success or failure).

Will do.  Do you plan this for 23.3, or just for the trunk?  If the
latter, I'd like to unbreak the Windows build on the trunk first.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Do you have the exact link errors?  If possible, please try with this
>> patch (the libpng API changes are a bit of a mess, and it's possible
>> that small changes might affect success or failure).
>
> Will do.  Do you plan this for 23.3, or just for the trunk?  If the
> latter, I'd like to unbreak the Windows build on the trunk first.

I'd like to get this into 23.3, to help future-proof that release.
If we wrap the changes in "#if (PNG_LIBPNG_VER < ...)" checks, I assume
it will be reasonably safe.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Thomas Klausner <tk@giga.or.at>, 7908@debbugs.gnu.org
> Date: Tue, 25 Jan 2011 15:57:38 -0500
> 
> > This doesn't work, I tried that a few weeks ago, and I still get link
> > errors.
> 
> Do you have the exact link errors?  If possible, please try with this
> patch (the libpng API changes are a bit of a mess, and it's possible
> that small changes might affect success or failure).

With this patch, image.c doesn't compile:

  image.c: In function `png_load':
  image.c:5866: error: invalid type argument of `unary *'

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> With this patch, image.c doesn't compile:
>
>   image.c: In function `png_load':
>   image.c:5866: error: invalid type argument of `unary *'

Hmm, interesting.  That line compiles fine on GNU/Linux.  Could you
double check if you used the second (corrected) patch I sent?  Line 5866
should read

  if (setjmp (PNG_JMPBUF (png_ptr)))

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: tk@giga.or.at,  7908@debbugs.gnu.org
> Date: Sat, 29 Jan 2011 10:44:19 -0500
> 
> >   image.c: In function `png_load':
> >   image.c:5866: error: invalid type argument of `unary *'
> 
> Hmm, interesting.  That line compiles fine on GNU/Linux.  Could you
> double check if you used the second (corrected) patch I sent?  Line 5866
> should read
> 
>   if (setjmp (PNG_JMPBUF (png_ptr)))

Sorry, I used an old patch.  But with this line corrected, the
compilation still fails with the same error message.

(I'm using libpng 1.4.x here, but I modified the #ifdef conditionals
to make the new code in effect on 1.4.x.  Maybe that's the reason for
the difference?)

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I used an old patch.  But with this line corrected, the
> compilation still fails with the same error message.
>
> (I'm using libpng 1.4.x here, but I modified the #ifdef conditionals
> to make the new code in effect on 1.4.x.  Maybe that's the reason for
> the difference?)

Yeah, it makes a big difference.  png_set_longjmp_fn is new to
libpng-1.5, it's the new non-backward compatible way to access the png
jmpbuf.

If it's too much trouble for you to install libpng 1.5 on Windows, I
think I'll go ahead and commit the patch.  The way the conditionals are
now written, compilation with libpng 1.4 is unaffected, so it should be
very safe.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: tk@giga.or.at, 7908@debbugs.gnu.org
> Date: Sat, 29 Jan 2011 13:29:32 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I used an old patch.  But with this line corrected, the
> > compilation still fails with the same error message.
> >
> > (I'm using libpng 1.4.x here, but I modified the #ifdef conditionals
> > to make the new code in effect on 1.4.x.  Maybe that's the reason for
> > the difference?)
> 
> Yeah, it makes a big difference.  png_set_longjmp_fn is new to
> libpng-1.5, it's the new non-backward compatible way to access the png
> jmpbuf.

But I do see png_set_longjmp_fn in png.h from libpng 1.4.3:

  #ifdef PNG_SETJMP_SUPPORTED
  /* This function returns the jmp_buf built in to *png_ptr.  It must be
   * supplied with an appropriate 'longjmp' function to use on that jmp_buf
   * unless the default error function is overridden in which case NULL is
   * acceptable.  The size of the jmp_buf is checked against the actual size
   * allocated by the library - the call will return NULL on a mismatch
   * indicating an ABI mismatch.
   */
  extern PNG_EXPORT(jmp_buf*, png_set_longjmp_fn)
     PNGARG((png_structp png_ptr, png_longjmp_ptr longjmp_fn, size_t
	 jmp_buf_size));
  #  define png_jmpbuf(png_ptr) \
     (*png_set_longjmp_fn((png_ptr), longjmp, sizeof (jmp_buf)))
  #else
  #  define png_jmpbuf(png_ptr) \
     (LIBPNG_WAS_COMPILED_WITH__PNG_NO_SETJMP)
  #endif

Could it be that image.c compiles for you on GNU/Linux because
DEF_IMGLIB_FN and LOAD_IMGLIB_FN are not compiled except on Windows?

> If it's too much trouble for you to install libpng 1.5 on Windows, I
> think I'll go ahead and commit the patch.

There's no Windows port of libpng 1.5 yet, but I will at least try
compiling with the headers from there.

> The way the conditionals are now written, compilation with libpng
> 1.4 is unaffected, so it should be very safe.

Yes, but if we want Emacs 23.3 to be stable until Emacs 24.1 is
released, we better make it compatible with libpng 1.4.x.  So I'd
prefer that you wait until we understand this issue, if not resolve
it.  Thanks.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> Date: Sat, 29 Jan 2011 21:02:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 7908@debbugs.gnu.org, tk@giga.or.at
> 
> There's no Windows port of libpng 1.5 yet, but I will at least try
> compiling with the headers from there.

Tried that now.  Same error message.

Does this alternate definition of PNG_JMPBUF make sense?

  #define PNG_JMPBUF(ptr) \
    (*(jmp_buf *)(fn_png_set_longjmp_fn((ptr), longjmp, sizeof (jmp_buf))))

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Does this alternate definition of PNG_JMPBUF make sense?
>
> #define PNG_JMPBUF(ptr) \
>   (*(jmp_buf *)(fn_png_set_longjmp_fn((ptr), longjmp, sizeof (jmp_buf))))

Aha, I think it makes sense.  Since DEF_IMGLIB_FN defines a return type
of int, whereas fn_png_set_longjmp_fn actually returns a (jmp_buf *), we
do indeed need to perform the extra cast.  Well spotted.  Does Emacs
compile properly with this change?

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: 7908@debbugs.gnu.org, tk@giga.or.at
> Date: Sat, 29 Jan 2011 15:33:00 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does this alternate definition of PNG_JMPBUF make sense?
> >
> > #define PNG_JMPBUF(ptr) \
> >   (*(jmp_buf *)(fn_png_set_longjmp_fn((ptr), longjmp, sizeof (jmp_buf))))
> 
> Aha, I think it makes sense.  Since DEF_IMGLIB_FN defines a return type
> of int, whereas fn_png_set_longjmp_fn actually returns a (jmp_buf *), we
> do indeed need to perform the extra cast.  Well spotted.  Does Emacs
> compile properly with this change?

Yes, it does.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Aha, I think it makes sense.  Since DEF_IMGLIB_FN defines a return type
>> of int, whereas fn_png_set_longjmp_fn actually returns a (jmp_buf *), we
>> do indeed need to perform the extra cast.  Well spotted.  Does Emacs
>> compile properly with this change?
>
> Yes, it does.

Excellent.  I've committed the corrected patch.  Thanks very much for
helping fix this.

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Does this alternate definition of PNG_JMPBUF make sense?
>>
>> #define PNG_JMPBUF(ptr) \
>>   (*(jmp_buf *)(fn_png_set_longjmp_fn((ptr), longjmp, sizeof (jmp_buf))))
>
> Aha, I think it makes sense.  Since DEF_IMGLIB_FN defines a return type
> of int, whereas fn_png_set_longjmp_fn actually returns a (jmp_buf *), we
> do indeed need to perform the extra cast.

You can't expect this to work, though.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Chong Yidong]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Aha, I think it makes sense.  Since DEF_IMGLIB_FN defines a return type
>> of int, whereas fn_png_set_longjmp_fn actually returns a (jmp_buf *), we
>> do indeed need to perform the extra cast.
>
> You can't expect this to work, though.

Hmm, true.  So maybe something like this instead?

*** src/image.c	2011-01-29 21:28:26 +0000
--- src/image.c	2011-01-29 22:26:51 +0000
***************
*** 5592,5598 ****
  
  #if (PNG_LIBPNG_VER >= 10500)
  DEF_IMGLIB_FN (png_longjmp);
! DEF_IMGLIB_FN (png_set_longjmp_fn);
  #endif /* libpng version >= 1.5 */
  
  static int
--- 5592,5598 ----
  
  #if (PNG_LIBPNG_VER >= 10500)
  DEF_IMGLIB_FN (png_longjmp);
! jmp_buf* (FAR CDECL *fn_png_set_longjmp_fn);
  #endif /* libpng version >= 1.5 */
  
  static int

bug#7908: png-1.5 fix for emacs-23.2 and HEAD

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>> Aha, I think it makes sense.  Since DEF_IMGLIB_FN defines a return type
>>> of int, whereas fn_png_set_longjmp_fn actually returns a (jmp_buf *), we
>>> do indeed need to perform the extra cast.
>>
>> You can't expect this to work, though.
>
> Hmm, true.  So maybe something like this instead?

I've checked in a proper fix, though I can't test it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."