| Age | Commit message (Collapse) | Author |
|---|
|
Remove one left warning from GN Release build.
Review URL: https://codereview.chromium.org/1904473003
|
|
This is a result of looking for the anti-paterns /char\*\sm_/
and /m_.*=.*\.c_str/ which indicate that a class may be using
the contents of a string without extending the lifetime of
the underlying storage.
Along the way, change to uint8_t in fx_dib; this is unrelated but
avoids grep hits (it is binary, not chars anyways).
Also remove two string operators that make it easy to assign in
a manner that does not extend contents lifetime.
Review URL: https://codereview.chromium.org/1902953002
|
|
This will help avoid duplicate allocation of CFX_ByteStrings
when the caller already has one. It may seem counter-intuitive
that requiring the caller to pass an allocated CFX_ByteString
rather than a static CFX_ByteStringC would improve the situation,
but due to the idiosyncrasies of std::map, the CPDF_Dictionary
methods must always do an allocation under the covers which
can't be avoided.
The changed callers in this CL are places where we would
previously demote to CFX_ByteStringC and then allocate a
a duplicate CFX_ByteString in the dictionary method.
Review URL: https://codereview.chromium.org/1889863002
|
|
BUG=
Review URL: https://codereview.chromium.org/1885973002
|
|
Replace the usage of CFX_ArrayTemplate inside CPDF_Array, which
has non-standard APIs such as GetSize() returns int.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1867183002 .
|
|
The naming is redundant given the base type, and will stand
in the way of consolidating Byte and Wide code.
BUG=
Review URL: https://codereview.chromium.org/1862123003
|
|
It doesn't persist the string beyond the duration of the
call, hence it should take the *StringC variant. Doing so
avoids some allocs by changing to the *StringC ctor in a few
places, at the cost of some explicit .ToByteStringC() calls
(which are cheap).
Review URL: https://codereview.chromium.org/1862953004
|
|
This CL moves the last two fpdfdoc files from core/include/fpdfdoc to
core/fpdfdoc/include.
Review URL: https://codereview.chromium.org/1864163002
|
|
Having this happen implicitly can be dangerous because the lifetime
has to be considered; we should have caught the "red bots" in
https://codereview.chromium.org/1847333004/#ps60001 at compile time.
Review URL: https://codereview.chromium.org/1853233002
|
|
Every time I read this code, I have to make the mental substituion
that "Element value" means "de-ref indirect object", so it might
as well just say so.
BUG=
Review URL: https://codereview.chromium.org/1841173002
|
|
Review URL: https://codereview.chromium.org/1832173003
|
|
This CL splits apart the core/include/fpdfapi/fpdf_resource.h file and places
the classes into individual files.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1824033002 .
|
|
It isn't buying us anthing, and it looks strange in
a struct when other uint types are already present.
R=dsinclair@chromium.org
Review URL: https://codereview.chromium.org/1821043003 .
|
|
This CL splits the fpdf_page.h header into the individual classes and moves
them to the correct core/fpdfapi locations.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1805663002 .
|
|
This Cl moves a bunch of the files from core/include/fpdfapi to their correct
location outside the core/include tree.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1805603002 .
|
|
This CL moves the core/src/ files up to core/ and fixes up the include guards,
includes and build files.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1800523005 .
|
