CVE-2015-8126: Multiple buffer overflows in libpng

Re:CVE-2015-8126: Multiple buffer overflows in libpng by zanny on Saturday November 14, 2015 @03:43PM (#10567158)

Any sane library should be using a stable ABI. Qt does it with giant libraries but any software compiled against any 5.x release will work with any of them since they require ABI stability. You don't even need to ABI break on new features if you use PIMPL right. Its only when you change your API function signatures that already exist that you break the ABI. And thats the way every library should be.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by tedunangst on Saturday November 14, 2015 @05:15PM (#10567502)

Most libraries are not sane. API breaks are common, and often security updates are only available in new, incompatible releases.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by zanny on Saturday November 14, 2015 @06:54PM (#10567831)

Then don't use those libraries! How can you trust a third party library to provide functionality to your software if they cannot even release sanely with ABI stability? Its a disservice to you and your users to risk security vulnerabilities like this.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by throwaway2048 on Saturday November 14, 2015 @09:40PM (#10568263)

with tons of functionality there is no realistic alternative.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by librarian42 on Sunday November 15, 2015 @09:46AM (#10569722)

Simplify the interface. Don't combine unrelated functionality in a single library.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by rewqfdsa on Saturday November 14, 2015 @04:27PM (#10567339)

PIMPL is an inefficient antipattern when the holder object is itself heap-allocated. You're better off coding against interfaces, COM-style.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by zanny on Saturday November 14, 2015 @06:37PM (#10567794)

It doesn't matter if your holder is heap or stack allocated, the d pointer is always heap allocated and the only reference to it is the private internal. With interfaces you either have an awful dummy static constructor for your private object somewhere or you have a non-virtual parent class with dummy implementations of all its functions and a mangled constructor that produces its private child.

For the developer, interfaces are cleaner, but for users, the interface style is leaky where PIMPL is not. That makes it superior. It also avoids overriding the intent of inheritance as a way of achieving ABI compatibility when it already has a significant and intentional function of runtime polymorphism, and can easily confuse users as to whether the implementation is to preserve the ABI or provide multiple implementations in the same release.

[ Parent | on HN ]

Re:CVE-2015-8126: Multiple buffer overflows in libpng by rewqfdsa on Sunday November 15, 2015 @11:52PM (#10572668)

Right, so if your holder object is heap-allocated, you need to dereference a pointer so that you can then call into the implementation. That's inefficient, bad for the cache, and puts needless pressure on the heap allocator. C++ classes built out of pure virtual member functions are just as compatible. If you use something COM-like, you can reference-count and manage them in a uniform way.

PIMPL as commonly described is a waste of good electricity, like most design patterns. Especially because most of the time I see it used, it's from the keyboard of some well-meaning but inexperienced developer who doesn't even need to maintain binary compatibility.

[ Parent | on HN ]