From dba61da1bfb7e4d74c723f369d1c017df9707a14 Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Thu, 8 Sep 2022 08:03:57 -0400 Subject: Create a special "destroyed" type rather than using null When a QPDF is destroyed, changing indirect objects to direct nulls makes them effectively disappear silently when they sneak into other places. Instead, we should treat this as an error. Adding a destroyed object type makes this possible. --- manual/release-notes.rst | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'manual/release-notes.rst') diff --git a/manual/release-notes.rst b/manual/release-notes.rst index 9cf09840..bf6a8301 100644 --- a/manual/release-notes.rst +++ b/manual/release-notes.rst @@ -202,11 +202,13 @@ For a detailed list of changes, please see the file ``replaceKeyAndGetOld``, a ``null`` object if the object was not previously there. - - The method ``QPDFObjectHandle::getOwningQPDF`` now returns a - null pointer (rather than an invalid pointer) if the owning - ``QPDF`` object has been destroyed. This situation should - generally not happen for correct code, but at least the - situation is detectible now. + - It is now possible to detect when a ``QPDFObjectHandle`` is an + indirect object that belongs to a ``QPDF`` that has been + destroyed. Any attempt to unparse this type of + ``QPDFObjectHandle`` will throw a logic error. You can detect + this by calling the new ``QPDFObjectHandle::isDestroyed`` + method. Also the ``QPDFObjectHandle::getOwningQPDF`` method now + returns a null pointer rather than an invalid pointer. - The method ``QPDFObjectHandle::getQPDF`` returns a ``QPDF&`` (rather than a ``QPDF*``) and is an alternative to -- cgit v1.2.3-54-g00ecf