Please be very careful when using less popular C/C++ image parsing libraries on anything that is user-controlled or that comes from the Internet.
Image, multimedia, and archive parsing are notoriously prone to security bugs. In fact, so are most other types of complex parsing. There are months of researcher work and decades of CPU time that went into auditing and fuzzing libraries such as libpng or libjpeg-turbo, identifying and fixing lots of vulnerabilities. The same isn't true for libraries with much smaller following, especially if their documentation doesn't contain any discussion of security risks and countermeasures taken.
And a quick glance shows that the code isn't written in a terribly obvious and defensive manner. For example, just by skimming you can spot loads and loads of unchecked arithmetic. How can you know none of that can be exploited? The code doesn't do a lot to assure you of that.
its a very good cross platform bit of code. even though it has some annoying compiler warnings, i've managed to get this to work just fine on Windows, Mac, Linux (ubuntu, CentOS, RHEL at least...), Android (even the obscure mips configs), iOS, Windows Phone 8, Windows 8 Store and other platforms that must remain nameless.
As is mentioned elsewhere in the thread: this does not seem to be secure software. As such, think twice about using this: do you really want anyone within NFC range to be able to exploit your app?
Of course using a secure library is preferred. Though it's really hard to use something that isn't very well documented and I just have a few months of experience working with C. Which is also a potential dangerous combination.
I found another library that wraps libpng https://github.com/nilx/io_png
Maybe I could be more successful with that library.
I don't know if the URL has changed or something, but:
> LodePNG is a PNG image decoder and encoder, all in one, no dependency or linkage to zlib or libpng required.
It's made for C (ISO C90), and has a C++ wrapper with a more convenient interface on top.
Or you mean the title here in HN? That's an unfortunate consequence of the "keep titles verbatim" rule.
> That's an unfortunate consequence of the "keep titles verbatim" rule
I fear that you're misunderstanding the rule a little. There's nothing wrong with including an explanatory phrase from a subtitle, or from the introductory sentence of the page, which is often a de facto subtitle. (We added that when we saw this title earlier today). What we're strict about avoiding is submitters rewriting titles to make their own point about the content, rather than preserving what the author wrote.
Image, multimedia, and archive parsing are notoriously prone to security bugs. In fact, so are most other types of complex parsing. There are months of researcher work and decades of CPU time that went into auditing and fuzzing libraries such as libpng or libjpeg-turbo, identifying and fixing lots of vulnerabilities. The same isn't true for libraries with much smaller following, especially if their documentation doesn't contain any discussion of security risks and countermeasures taken.