|
»
Libpng-1.4.0 versus libpng-1.2.41
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
Here is a list of most changes from 1.2.x to 1.4.x, extracted
from libpng*.txt and with some commentary (indented). I think the only pressure to release 1.4.0 is to gain iTXt support. None of the other changes seem to me to matter enough to warrant quickly pushing out a new release. IX. Changes to Libpng from version 1.0.x/1.2.x to 1.4.x Private libpng prototypes and macro definitions were moved from png.h and pngconf.h into a new pngpriv.h header file. This must wait for 1.4.0 Support for the iTXt chunk has been enabled by default. Could probably be added to 1.2.41 but would be somewhat ugly. The decision whether to release 1.4.0 soon or to proceed with 1.2.41 hinges on this. Support for global arrays was removed. This must wait for 1.4.0 Some obsolete/deprecated macros and functions have been removed. This must wait for 1.4.0 These macros are deprecated: PNG_READ_TRANSFORMS_NOT_SUPPORTED PNG_PROGRESSIVE_READ_NOT_SUPPORTED PNG_NO_SEQUENTIAL_READ_SUPPORTED PNG_WRITE_TRANSFORMS_NOT_SUPPORTED PNG_READ_ANCILLARY_CHUNKS_NOT_SUPPORTED PNG_WRITE_ANCILLARY_CHUNKS_NOT_SUPPORTED They have been replaced, respectively, by: PNG_NO_READ_TRANSFORMS PNG_NO_PROGRESSIVE_READ PNG_NO_SEQUENTIAL_READ PNG_NO_WRITE_TRANSFORMS PNG_NO_READ_ANCILLARY_CHUNKS PNG_NO_WRITE_ANCILLARY_CHUNKS These are already in 1.2.41 The PNG_1_0_X and PNG_1_2_X macros were eliminated. This must wait for 1.4.0 The PNG_LEGACY_SUPPORTED macro was eliminated. This must wait for 1.4.0 Many WIN32_WCE #ifdefs were removed. This must wait for 1.4.0 PNG_MAX_UINT was replaced with PNG_UINT_31_MAX. It has been deprecated since libpng-1.0.16 and libpng-1.2.6. PNG_UINT_31_MAX is already in 1.2.x Removing PNG_MAX_UINT must wait for 1.4.0 The function png_check_sig(sig, num) was replaced with !png_sig_cmp(sig, 0, num) It has been deprecated since libpng-0.90. The functions png_read_init(info_ptr), png_write_init(info_ptr), png_info_init(info_ptr), png_read_destroy(), and png_write_destroy() have been removed. They have been deprecated since libpng-0.95. Removing these must wait for 1.4.0 The function png_set_gray_1_2_4_to_8() which also expands tRNS to alpha was replaced with png_set_expand_gray_1_2_4_to_8() which does not. It has been deprecated since libpng-1.0.18 and 1.2.9. png_set_expand_gray_1_2_4_to_8() is already in 1.2.x Removing png_set_gray_1_2_4_to_8() must wait for 1.4.0 Support for numbered error messages was removed by default, since we never got around to actually numbering the error messages. The function png_set_strip_error_numbers() was removed from the library by default. Removing this (or implementing numbered messages) must wait for 1.4.0 Functions png_set_benign_errors(), png_benign_error(), and png_chunk_benign_error() were added. Could be added to libpng-1.2.41 Support for setting the maximum amount of memory that the application will allocate for reading chunks was added, as a security measure. The functions png_set_chunk_cache_max() and png_get_chunk_cache_max() were added to the library. Could be added to libpng-1.2.41 We implemented support for I/O states. Added png_ptr member io_state, and functions png_get_io_chunk_name() and png_get_io_state() in pngget.c Can this be added to libpng-1.2.41? The png_permit_empty_plte() was removed. It has been deprecated since libpng-1.0.9. Use png_permit_mng_features() instead. Removing this must wait for 1.4.0 We removed the obsolete stub functions png_get_mmx_flagmask(), png_set_mmx_thresholds(), png_get_asm_flags(), png_get_mmx_bitdepth_threshold(), png_get_mmx_rowbytes_threshold(), png_set_asm_flags(), and png_mmx_supported() Removing these must wait for 1.4.0 We removed the png_memcpy_check() and png_memset_check() functions. These could be removed from 1.2.x since they are not exported. We changed the prototype for png_malloc() from png_malloc(png_structp png_ptr, png_uint_32 size) to png_malloc(png_structp png_ptr, png_alloc_size_t size) This must wait for 1.4.0 We changed the prototypes of png_get_compression_buffer_size() and png_set_compression_buffer_size() to work with png_size_t instead of png_uint_32. This must wait for 1.4.0 The png_zalloc() function no longer zeroes out the memory that it allocates. This must wait for 1.4.0 The png_zalloc() and png_zfree() functions are no longer exported. This must wait for 1.4.0 The png_calloc() function was added and is used in place of of "png_malloc(); png_memset();" except in the case in png_read_png() where the array consists of pointers; in this case a "for" loop is used after the png_malloc() to set the pointers to NULL. This could be added to libpng-1.2.41 We removed the trailing '.' from the warning and error messages. This must wait for 1.4.0 We added PNG_TRANSFORM_GRAY_TO_RGB to the available high-level input transforms. This could be added to libpng-1.2.41 The png_struct and info_struct members "trans" and "trans_values" were changed to "trans_alpha" and "trans_color", respectively. I think this must wait for 1.4.0 The call to png_do_chop() in pngrtran.c, which reduces 16-bit input files to 8-bit bit depth, was relocated ahead of the building of gamma tables. This allows us to build 8-bit tables instead of 16-bit tables, when only 8-bit tables are needed. This avoids wasting some computing resources when the application has called the png_set_strip_16() function and encounters a 16-bit PNG file. I think this could be done in libpng-1.2.41 Checking for and reporting of errors in the IHDR chunk is more thorough. This could be done in libpng-1.2.41 Bottom line: if I can figure a way of adding iTXt support to 1.2.41 in an API-compatible manner, we should go ahead with 1.2.41 instead of pushing out 1.4.0. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by glennrp-2
::
Rate this Message:
Oops, these two functions *are* exported so we can't remove them
from libpng-1.2.41. But, who cares? Glenn ----- Original Message ----- From: "Glenn Randers-Pehrson" <glennrp@...> We removed the png_memcpy_check() and png_memset_check() functions. These could be removed from 1.2.x since they are not exported. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by John Bowler-3
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>Here is a list of most changes from 1.2.x to 1.4.x, extracted >from libpng*.txt and with some commentary (indented). I think >the only pressure to release 1.4.0 is to gain iTXt support. I agree to some extent but on balance I think the vast majority of libpng using applications *just* decode the image (they don't even compress), and that there are a very small number that will ever use iTXt. Consequently the vast majority of libpng uses are best served by a stable 1.2 that only ever gets security patches. There's inadequate justification to add iTXt to 1.2 for precisely the same reason as there has been inadequate justification for all the past years. For 1.4 I agree with Bob - release 1.4.0 as soon as possible. I do suggest, however, that the #include required be: #include <png14.h> Otherwise it is impossible for someone examining the code of an application to deduce which API is in use without also examining the frequently incomprehensible build scripts. Libpng is used much too widely for an incompatible API change to be acceptable without this kind of support. John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>Here is a list of most changes from 1.2.x to 1.4.x, extracted >from libpng*.txt and with some commentary (indented). I think >the only pressure to release 1.4.0 is to gain iTXt support. I agree to some extent but on balance I think the vast majority of libpng using applications *just* decode the image (they don't even compress), and that there are a very small number that will ever use iTXt. Consequently the vast majority of libpng uses are best served by a stable 1.2 that only ever gets security patches. There's inadequate justification to add iTXt to 1.2 for precisely the same reason as there has been inadequate justification for all the past years. For 1.4 I agree with Bob - release 1.4.0 as soon as possible. I do suggest, however, that the #include required be: #include <png14.h> Otherwise it is impossible for someone examining the code of an application to deduce which API is in use without also examining the frequently incomprehensible build scripts. Libpng is used much too widely for an incompatible API change to be acceptable without this kind of support. John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 29, 2009 at 1:26 PM, John Bowler
<john.cunningham.bowler@...> wrote: > For 1.4 I agree with Bob - release 1.4.0 as soon as possible. I do suggest, > however, that the #include required be: > > #include <png14.h> I think that is a pretty good idea. That will quickly detect the situation where the application builder is using -lpng instead of -lpng12 and gets surprised by the change in behavior. The missing "png14.h" will make it pretty obvious what has happened. It does mean we have to modify the configure script and all of the scripts/makefile.* though. It's easy to find those, though, just search for "pngpriv.h". Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 29, 2009 at 1:30 PM, John Bowler <jbowler@...> wrote:
> There's inadequate justification > to add iTXt to 1.2 for precisely the same reason as there has been > inadequate justification for all the past years. I think there has been adequate justification for quite a while and we have been remiss in not implementing it. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Bob Friesenhahn
::
Rate this Message:
On Thu, 29 Oct 2009, John Bowler wrote:
> > For 1.4 I agree with Bob - release 1.4.0 as soon as possible. I do suggest, > however, that the #include required be: > > #include <png14.h> If this approach is used, then -lpng should never resolve to libpng 1.4. The user then always needs to be explicit about the desired version. Any automated configure script would need to test for the most desired version first, followed by less desirable versions. The configure script could provide an option so the user can specifify the desired PNG version to use. Since configure scripts rarely change, this means that 1.4 would rarely be used for quite some time. However, it does have the advantage that 1.4 could be deployed almost right away and make it into stable distributions faster. There would be problems if a library using 1.2 is linked with a library/application already using 1.4. Due to the way packages are managed, the explicit naming may actually cause more problems than are solved since there might not be a reliable way to trigger consistent rebuilds and use of the newer version (thinking of schemes like FreeBSD ports here). I agree that the vast majority of users are quite happy with libpng "as is" and only expect/want security fixes. This should not be used as an excuse to prevent libpng from continued forward progress though. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by John Bowler
::
Rate this Message:
From: Bob Friesenhahn [mailto:bfriesen@...]
>There would be problems if a library using 1.2 is linked with a >library/application already using 1.4. OK. I was actually suggesting changing the file name of png*.h to png*14.h (so even the 1.4.0 library source code uses '#include "png14.h"') How about adding (in addition): #define png_foo png_foo_14 in png.h for every exported symbol? (I.e. in the manner of the 'Z_PREFIX' stuff in zconf.h.) Certainly 1.4.0 should be a separate package (e.g. 'libpng14' not 'libpng') - otherwise it is almost inconceivable that it will ever get used. (How could it - so many libraries and apps use it, they would all have to be updated at once *and* all tested at once!) John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
OK, I think I've seen about enough to convince me to go ahead
with libpng-1.2.41 and let libpng-1.4.0 stay in beta nearly forever. I would like a definitive answer to whether it is still ok to *add* functions and png_struct members. We have done it a few times, the most recent being png_check_cHRM() in libpng-1.2.34. The most recent addition to png_struct was png_chunkdata in libpng-1.2.30. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Bob Friesenhahn
::
Rate this Message:
On Thu, 29 Oct 2009, Glenn Randers-Pehrson wrote:
> OK, I think I've seen about enough to convince me to go ahead > with libpng-1.2.41 and let libpng-1.4.0 stay in beta nearly forever. > > I would like a definitive answer to whether it is still ok to *add* > functions and png_struct members. We have done it a few times, > the most recent being png_check_cHRM() in libpng-1.2.34. > The most recent addition to png_struct was png_chunkdata > in libpng-1.2.30. It should be generally ok to add new functions and to add to dynamically-allocated structures, as long as the additions are always appended. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
|
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Bob Friesenhahn
::
Rate this Message:
On Thu, 29 Oct 2009, glennrp@... wrote:
> It should be generally ok to add new functions and to add to > dynamically-allocated structures, as long as the additions are always > appended. > > I'd rather see an answer along the lines of > "It is always ok to ...." Unfortunately, it is possible to find (rare) exceptions to these rules. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Alexander Shulgin-2
::
Rate this Message:
On Thu, Oct 29, 2009 at 20:32, John Bowler <jbowler@...> wrote:
> From: Bob Friesenhahn [mailto:bfriesen@...] >>There would be problems if a library using 1.2 is linked with a >>library/application already using 1.4. > > OK. I was actually suggesting changing the file name of png*.h to png*14.h > (so even the 1.4.0 library source code uses '#include "png14.h"') > > How about adding (in addition): > > #define png_foo png_foo_14 > > in png.h for every exported symbol? (I.e. in the manner of the 'Z_PREFIX' > stuff in zconf.h.) Whoa, you taking things to the extreme. Are you serious? I mean, we have separate libpng12-config and libpng14-config scripts already. So when build scripts are using the latter one it clearly indicates that 1.4 is intended. May be we shouldn't install an unversioned symlink libpng-config -> libpng14-config by default just yet as current users of 1.2 most certainly use unversioned libpng-config? This also goes for an unversioned libpng.so for sure: don't do it just yet. -- Alex ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Alexander Shulgin-2
::
Rate this Message:
On Thu, Oct 29, 2009 at 19:32, Glenn Randers-Pehrson <glennrp@...> wrote:
> On Thu, Oct 29, 2009 at 1:26 PM, John Bowler > <john.cunningham.bowler@...> wrote: > >> For 1.4 I agree with Bob - release 1.4.0 as soon as possible. I do suggest, >> however, that the #include required be: >> >> #include <png14.h> > > I think that is a pretty good idea. That will quickly detect the situation > where the application builder is using -lpng instead of -lpng12 and gets > surprised by the change in behavior. The missing "png14.h" will make > it pretty obvious what has happened. Are you talking about some specific anticipated change in behavior in 1.4 vs 1.2 or is it hypothetical? From the changes you listed above I don't expect very much difference in it. In fact, it might not compile, but when it did, it most probably would go smooth (except for possible introduced bugs, of course). -- Alex ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
On Fri, Oct 30, 2009 at 2:12 AM, Alexander Shulgin
<alex.shulgin@...> wrote: > On Thu, Oct 29, 2009 at 19:32, Glenn Randers-Pehrson <glennrp@...> wrote: >> On Thu, Oct 29, 2009 at 1:26 PM, John Bowler >> <john.cunningham.bowler@...> wrote: >> >>> For 1.4 I agree with Bob - release 1.4.0 as soon as possible. I do suggest, >>> however, that the #include required be: >>> >>> #include <png14.h> >> >> I think that is a pretty good idea. That will quickly detect the situation >> where the application builder is using -lpng instead of -lpng12 and gets >> surprised by the change in behavior. The missing "png14.h" will make >> it pretty obvious what has happened. > > Are you talking about some specific anticipated change in behavior in > 1.4 vs 1.2 or is it hypothetical? I was referring to change in behavior of the user's build/link process. Once libpng is installed the only changes in behavior I would expect are avoiding unnecessary building of 16-bit gamma tables when the output is 8-bit, and the improved error-checking of the IHDR data. I think the rest of the changes are new features that the users won't notice unless they use them. They also might notice a slightly larger memory footprint of the library and the png_struct. > From the changes you listed above I don't expect very much difference > in it. In fact, it might not compile, but when it did, it most > probably would go smooth (except for possible introduced bugs, of > course). As someone pointed out yesterday, I am elderly, so you can count on getting those. I'm counting on the rest of you to test, test, test. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
Sent: Thursday, October 29, 2009 11:46 AM >OK, I think I've seen about enough to convince me to go ahead >with libpng-1.2.41 and let libpng-1.4.0 stay in beta nearly forever. Ok, maybe what I was suggesting (ensuring 1.2 and 1.4 can co-exist on the same system) is too scary. My suggestions were motivated by the idea that 1.4.0 would actually get released downstream. After a little thought I don't think that's true. The problem is that 1.4.0 is actually hidden away inside 'png-group' on ftp.simplesystems.org. No system builder is going to touch it. So, rather than abandoning 1.4 just drop 1.4.0 into 'png' and advertize it as the next *ABI and API incompatible* version. System builders are intelligent enough not to release it, but on gentoo at least it will become available as a masked package and then all the other package maintainers will automatically fix any API issues! (We're talking very very minor API changes here, not a major rewrite.) John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
On Sat, Oct 31, 2009 at 5:20 PM, John Bowler <jbowler@...> wrote:
ng to touch it. > > So, rather than abandoning 1.4 just drop 1.4.0 into 'png' and advertize it > as the next *ABI and API incompatible* version. That has been the plan all along. I spent most of the day working with pngset.c. I'm convinced that it is unsafe to enable iTXt in 1.2.x by default, and that there is no satisfactory way of modifying libpng-1.2.x to make it safe to do so. The problematic statements are these: { /* Set iTXt data */ if (text_ptr[i].lang != NULL) lang_len = png_strlen(text_ptr[i].lang); else lang_len = 0; if (text_ptr[i].lang_key != NULL) lang_key_len = png_strlen(text_ptr[i].lang_key); else lang_key_len = 0; } If the caller was built with libpng-1.2.40, then the lang and lang_key elements are not present in the caller. libpng-1.2.41 doesn't know this, and the elements might contain gargage rather than NULL, so goes ahead and runs png_strlen() on them, perhaps reaching outside of the caller's allocated memory. We could avoid these tests if PNG_FLAG_LIBRARY_MISMATCH is set, but then we'd also be losing these members when the caller's original library was built with PNG_iTXT_SUPPORTED, which would be wrong. It would have to be a very rare situation, where a non-iTXt-supporting application sets the compression byte to 1 or 2. But not rare if someone is using to try to break libpng. With the release of 1.2.41, iTXt support will be the only meaningful difference between 1.2.x and 1.4.0. The rest of the changes are simply getting rid of deprecated functions and some typedef changes. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>On Sat, Oct 31, 2009 at 5:20 PM, John Bowler <jbowler@...> wrote: >> So, rather than abandoning 1.4 just drop 1.4.0 into 'png' and advertize it >> as the next *ABI and API incompatible* version. > >That has been the plan all along. Ok. Attached is an 'ebuild' and corresponding Manifest entries for a gentoo package. Note that the gentoo package builder made the same assumption I did - that major versions can co-exist - and consequently I had to remove the 'SLOT' from the ebuild to allow it to overwrite the 1.2 files. This package installs fine on my system and leaves 46 packages to be rebuilt (because libpng12.so gets zapped as a result of libpng-1.2.38 being removed - the gentoo package maintainer probably knows how to fix this...) I'm investigating package build failures now. Unfortunately the very first one, directfb, fails trying to access 'trans' and 'trans_values' in png_info. John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Glenn Randers-Pehrson
::
Rate this Message:
On Sat, Oct 31, 2009 at 8:25 PM, John Bowler <jbowler@...> wrote:
> Note that the gentoo package builder made the same assumption I did - that > major versions can co-exist - and consequently I had to remove the 'SLOT' > from the ebuild to allow it to overwrite the 1.2 files. They are supposed to be able to coexist. That's why they have different names: libpng10, libpng12, and libpng14. It is the fallback "libpng" that gets overwritten with the last one to be installed. But even then we have libpng.so.3, libpng.so.4 (libpng.so.5 on FreeBSD), and libpng.so.14, for old apps that require a particular shared library version. The only one that's ambigous is libpng.a. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
|
|
Re: Libpng-1.4.0 versus libpng-1.2.41
by Bob Friesenhahn
::
Rate this Message:
On Sat, 31 Oct 2009, Glenn Randers-Pehrson wrote:
> > They are supposed to be able to coexist. That's why they have different > names: libpng10, libpng12, and libpng14. It is the fallback "libpng" that > gets overwritten with the last one to be installed. But even then we > have libpng.so.3, libpng.so.4 (libpng.so.5 on FreeBSD), and libpng.so.14, > for old apps that require a particular shared library version. The only > one that's ambigous is libpng.a. It seems that the situation is considerably less terrible than was originally assumed. The proposal to spin up libpng 1.4.X so that it can enter stable OS distributions in a couple of years still stands. This gives plenty of time to make sure that any bugs are wrung out rather than trying to add features to the stable version. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ png-mng-implement mailing list png-mng-implement@... https://lists.sourceforge.net/lists/listinfo/png-mng-implement |
libpng-1.4.0.ebuild (951 bytes) | < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
