Pdfium reads the page number from the field of '/Count' but it can't
load the number assigned by this field due to the damaged data. Add a
check to ensure that the required page should be one of loaded pages.

Add a null check before getting unicode text in CPDF_FormField::GetValue

The test pdf file defines an invalid dictionary object with a NULL arrary
in the filed of "/V". It causes that a NULL object is returned when trying
to get the first element of this arrary. So it needs to check whether the
returned object is NULL.

Add a null pointer check before getting the family name of the given color space in CPDF_ColorSpace::Load

The test file defines a wrong color space object (7 0 obj). In the content of 7 0 obj,
the reserved obj (0 0 R) is used. The process of loading color space returns NULL when
the reserved obj (0 0 R) is found. For the error color space, it only needs to return
NULL when an error is detected.

Should there be cases where this fails to compile, it indicates a mistake,
either an incorrectly declared overrriden virtual method, or a method that
should be declared non-virtual.

The only issues were with CPDF_CustomAccess::GetBlock(), CPDF_CustomAccess::GetByte(),
and CPDF_CustomAccess::GetFullPath(). These don't appear to be used anywhere,
and are removed. Two members are removed that are no longer needed once those
methods are removed.

The root cause of this issue is shown as below:
Patterns are managed in CPDF_DocPageData. When
a document is closed, all patterns will be
released in the deconstruction of CPDF_DocPageData.
However, some patterns which are referenced in
CPDF_Color can't get the notification from the
destroy of CPDF_DocPageData. It will cause
use-after-free in CPDF_Color::~CPDF_Color.

When newPos == file size, the current block will not be read or Get. If this block is a crucial part of the document (like m_pTrailer), the program will exit with parse error and
the document will not be rendered.

Since exceptions are in the process of being removed,
and the code currently isn't rollable into pdfium (for other
reasons) I'm going to revert this for now, so that this CL
doesn't become blocking-for-rolls if the other min/max problem
is addressed.

And, hopefully by the time I get back to this it won't be
necessary anyway.

When an image object is zoomed in by a big factor, the scaling factor in the transformation matrix is big as well, resulting in a large |dest_width| and |dest_height| value(they can be think of as the equivalent pixel size of the entire image, although most of it is outside the device).

It looks like someone added the nFlag parameter to the methods in CPWL_Wnd
at some point and missed to update all overloads This patch attempts to fix this:
It adds the parameter to all methods that look like they're trying to overload the base
class method, and renames the method in one case where it fairly clearly looks like
that it's not supposed to be an overload.

On Windows, I believe MSVS treats these as override since it's such a common and
easy mistake, but clang and gcc do what the standard specifies. Add a "const" to
the function in the subclass so that this is actually an override, as intended.

If somehow different length values could be obtained by two successive calls
to Doc_getFilePath() (and FieldBrowse() for that matter), and the method is
true to the API documentation that says "The return value always indicated
number of bytes required for the buffer, even when there is no buffer
specified, or the buffer size is less then required", then it is possible
to get a returned length describing memory beyond the current buffer.

We can make the corresponding JS_docGetFilePath() method more robust against
this case by applying better checks to the returned value.

This probably is unrelated since ASAN seems to be flagging the corresponding bug
as UAF, but doesn't hurt to make things more robust.

- Remove more unused variables, functions, member variables.
- Put a few constructor initializers in the order they execute in.
- Add braces for subobject initializers.
- Fix a handful of signed / unsigned comparisons.

The methods are only defined in the cpp and thus can't always be inlined,
the methods are virtual and so can only be inlined when the concrete type
is known, and inline functions need their definition available in all
translation units.

Calling `delete` on an object of a type that has virtual functions but
not a virtual destructor is questionable: Since the object has virtual functions,
it likely has subclasses, so if it's deleted through the base pointer and the
destructor isn't virtual, the subclass destructor won't be called.

In most cases, the classes getting deleted can just be marked final to tell
the compiler that it can't possibly have subclasses (this also enables the
compiler to generate better code).

Two classes didn't have any sub- or superclasses but virtual functions -
this doesn't make sense, so make all methods of these classes non-virtual.
(Also delete an unused function on one of the two classes.)

In one case, a class actually did have a subclass that needs to be deleted
virtually, so mark one destructor as virtual.

C++11 makes uninitialized const PODs an error, because they contain
uninitialized memory (they're uninitialized that can never be initialized
(because they're const).

In this case, the memory was only used by _GetSubFontName() if the lang
parameter was 1, but _GetSubFontName() is only called from one place, with
a lang parameter of 0. So remove _GetSubFontName()'s lang parameter too.

(Using bsearch for searching an array that always has exactly 2 entries is
overkill too, but I'm trying to keep the diff small.)