1. 16 Nov, 2018 2 commits
  2. 04 Nov, 2018 1 commit
  3. 03 Nov, 2018 1 commit
  4. 31 Oct, 2018 1 commit
  5. 27 Oct, 2018 1 commit
  6. 24 Oct, 2018 1 commit
  7. 07 Oct, 2018 1 commit
  8. 05 Oct, 2018 2 commits
  9. 04 Oct, 2018 2 commits
  10. 03 Oct, 2018 1 commit
  11. 29 Sep, 2018 1 commit
  12. 24 Sep, 2018 1 commit
  13. 17 Sep, 2018 1 commit
  14. 16 Sep, 2018 2 commits
  15. 14 Sep, 2018 2 commits
  16. 13 Sep, 2018 10 commits
  17. 12 Sep, 2018 1 commit
  18. 10 Sep, 2018 3 commits
    • Debarshi Ray's avatar
      io-png: Clarify and fix the error handling · c2d50afb
      Debarshi Ray authored
      Neither png_create_read_struct* nor png_create_info_struct can trigger
      a longjmp out of libpng. That's only documented as being possible with
      png_set_progressive_read_fn, even though, currently, it does not.
      
      The documentation [1] is being a bit simplistic when it says:
        "... you will need to update the jmpbuf field every time you enter a
         new routine that will call a png_*() function"
      
      On closer look, the documentation for png_create_read_struct* [2] and
      png_create_info_struct [3] clarify that they return NULL on error and
      don't longjmp. This is borne out by the libpng code, comments and
      examples.
      
      In light of this, the assumption that the error callback would set the
      GError when either png_create_read_struct* or png_create_info_struct
      fails is wrong. These functions can only fail if there was a request
      to allocate an absurdly large amount of memory that exceeds one of the
      limits encoded in libpng; or if the memory allocator returns NULL; or
      if there was a ABI mismatch caused by compiling and running against
      incompatible libpng versions. All those are either programming or
      integration errors or something extremely catastrophic - normally one
      wouldn't bother handling them as run-time failures. However, since the
      libpng documentation repeatedly mentions that the return value from
      these functions should be checked, it's wise to do so.
      
      The current location of the setjmp is confusing to the reader because
      one can be misled into thinking that there's no need to check the
      value returned by png_create_info_struct, or that a failure will lead
      to the error handler and a longjmp. It's better to move it closer to
      the fallible png_set_progressive_read_fn.
      
      Fallout from e8d0d8ed
      
      [1] http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-3
      [2] http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng12.png.create.read.struct.1.html
      [3] http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng12.png.create.info.struct.1.html
      
      !16
      c2d50afb
    • Debarshi Ray's avatar
      io-png: Remove redundant NULL check · f7592463
      Debarshi Ray authored
      png_destroy_read_struct is safe against both a NULL png_infop and
      pointer to a NULL png_infop.
      
      Fallout from e8d0d8ed
      
      !16
      f7592463
    • Debarshi Ray's avatar
      io-png: Don't leak the png_infop in begin_load · 38060f93
      Debarshi Ray authored
      If lc->png_info_ptr is not NULL, then not passing it to
      png_destroy_read_struct will not release some resources.
      
      Fallout from e8d0d8ed
      
      !16
      38060f93
  19. 09 Sep, 2018 2 commits
  20. 06 Sep, 2018 3 commits
  21. 05 Sep, 2018 1 commit