OpenSystemsDevelopment / qpdf

Some files in the test suite trigger antivirus warnings. These are
not infected files with malicious intent. They are test files to
ensure that qpdf does not crash when it encounters the files. This
change enables those files to be obfuscated in the source repository
so that checking out qpdf from version control or extracting the
source code doesn't trigger antivirus warnings.

This fix allows qpdf to compile/test cleanly with gcc 8.

Rather than keeping a list of buffers for every write, accumulate
bytes in a single buffer, doubling the size of the buffer when needed
to accommodate new data.

This is not the best possible implementation, but the change was
implemented in this way to avoid changing the shape of Pl_Buffer and
thus breaking backward compatibility.

Reported in debian bug 902642

A previous fix introduced a potentially memory overrun under certain
rare conditions. The test suite now once again passes with address
sanitizer.

There were a few places in the code that were checking that a pointer
wasn't null before deleting it, even though C++ has always allowed
delete 0. Most of the code did not perform these checks.

CR, CRLF, and LF are all supposed to be treated as LF; only one EOL is
to be ignored after backslash.

Turns out you can keep adding zero to a number over and over again and
it just doesn't get any bigger. Who would have known?

A few public destructors were missing QPDF_DLL, which could cause some
Windows applications to fail to link.

During periods of intensive operation on a specific file, this method
can reduce the overhead of repeated open/close operations.

ClosedFileInputSource is an input source that keeps the file closed
when not reading it.

If we are unable to filter a page's content streams, don't attempt to
remove objects from the page's resource dictionary. Also provide a
command line option to suppress resource removal in case we ever need
this as a workaround for some bug or broken PDF files.

If parsing content streams is treated as a warning, there is no way
for a caller to know if a parsing operation has failed. This is very
dangerous and will likely result in data loss when token filters are
parser callbacks are in use.

It's not really a shallow copy. It just doesn't cross indirect object
boundaries. The old implementation had a bug that would cause multiple
shallow copies of the same object to share memory, which was not the
intention.

Remove form flattening
Clarify splitting/merging with document level constructs