Age | Commit message (Collapse) | Author |
|
Because that's what clone does. There are numerous
release() calls that will go away as more code is
converted.
Review-Url: https://codereview.chromium.org/2484033002
|
|
Otherwise, we might be silently doing an unsafe cast before
applying the check if the actual argument doesn't match the
exact src type.
Review-Url: https://codereview.chromium.org/2484953003
|
|
Follow-up from ParseIndirectObject() CL. This will get
cleaner once CPDF_Object::Clone itself returns unique_ptrs.
Pack some bools together while we're at it.
Review-Url: https://codereview.chromium.org/2479353002
|
|
In turn, propgate to callers. This introduces a few
release() calls that will go away as more code is converted.
It also removes a couple of WrapUnique calls that are no
longer needed as ownership of the object flows along.
Review-Url: https://codereview.chromium.org/2479303002
|
|
My OCD insists that classes be named after nouns, and "linearized"
feels like an adjective.
Remove a redundant "if" while at it.
Review-Url: https://codereview.chromium.org/2482973002
|
|
Unify some code
Move parsing of linearized header into separate CPDF_Linearized class.
Original review:
https://codereview.chromium.org/2466023002/
Revert review:
https://codereview.chromium.org/2474283005/
Revert reason was:
Breaking the chrome roll.
See https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331856
___
Added Fix for fuzzers.
Review-Url: https://codereview.chromium.org/2477213003
|
|
https://codereview.chromium.org/2466023002/ )
Reason for revert:
Breaking the chrome roll. See https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331856
Original issue's description:
> Unify some code
>
> Move parsing of linearized header into separate CPDF_Linearized class.
>
> Committed: https://pdfium.googlesource.com/pdfium/+/71333dc57ac7e4cf7963c83333730b3882ab371f
TBR=thestig@chromium.org,brucedawson@chromium.org,art-snake@yandex-team.ru
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2474283005
|
|
Move parsing of linearized header into separate CPDF_Linearized class.
Review-Url: https://codereview.chromium.org/2466023002
|
|
Review-Url: https://codereview.chromium.org/2477003002
|
|
Review-Url: https://codereview.chromium.org/2471263005
|
|
Now, we do not start traversal from where we were at, but from the top.
This makes the code less prone to bugs, as now there is no need to call
methods to recursively fix things. This will save a lot of time when
the trees are rather flat, as in the PDF file in the bug. It can still
be slow, for instance if we have a chain of page nodes, and the last
in the chain contains all of the pages (this is artificial).
Try 2 at https://codereview.chromium.org/2442403002/
Also added test where Try 2 would have failed.
Tested the pdf from the bug on my Mac:
With this CL: load in 21 seconds
Without this CL: did not load in 4 minutes, got tired of waiting
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2470803003
|
|
This reverts commit f0d5b6c35fa343108a3ab7a25bc2cc2b3cf105b3.
Review-Url: https://codereview.chromium.org/2478303002
|
|
Removes a path where it might not have taken ownership of an object,
at the expense of making callers check first. This eases making
the second argument an unique_ptr someday.
Review-Url: https://codereview.chromium.org/2475823002
|
|
#11 id:200001 of https://codereview.chromium.org/2384883003/ )
Reason for revert:
Looks like it's blocking the roll.
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/186619
Original issue's description:
> Remove CPDF_Object::Release() in favor of direct delete
>
> Follow-on once we prove Release always deletes in previous CL.
>
> Committed: https://pdfium.googlesource.com/pdfium/+/4de3d095c9d9e961f93750cf1ebd489fd515be12
TBR=thestig@chromium.org,tsepez@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2478253002
|
|
Follow-on once we prove Release always deletes in previous CL.
Review-Url: https://codereview.chromium.org/2384883003
|
|
- Added a private method to read a character.
- Added enum for parsing status.
- Deleted unused method.
Review-Url: https://codereview.chromium.org/2469833002
|
|
Making the insert methods private allows us to use private members, as I
will need on https://codereview.chromium.org/2470803003/
Review-Url: https://codereview.chromium.org/2472473005
|
|
Review-Url: https://codereview.chromium.org/2477443002
|
|
AES256_CheckPassword() leaks memory on failure.
Clean up some nits.
BUG=chromium:659468
Review-Url: https://codereview.chromium.org/2463183002
|
|
When linearized document have hint table,
The FPDFAvail_IsPageAvail return true,
but FPDF_LoadPage return nullptr, for non first pages.
This happens, bacause document not use hint tables, to load page.
To fix this, I force save the page's ObjNum in document.
This is restoring of original fix:
https://codereview.chromium.org/2437773003/
Review-Url: https://codereview.chromium.org/2444903002
|
|
#3 id:40001 of https://codereview.chromium.org/2442403002/ )
Reason for revert:
Not quite right yet.
Original issue's description:
> Traverse PDF page tree only once in CPDF_Document
>
> Try 2: main fix was recursively popping elements from the stack. Since
> the Traverse method can be called on non-root nodes from GetPage(), we
> have to make sure to properly update the parents.
>
> Try 1 at https://codereview.chromium.org/2414423002/
>
> In our current implementation of CPDF_Document::GetPage, we traverse
> the PDF page tree until we find the index we are looking for. This is
> slow when we do calls GetPage(0), GetPage(1), ... since in this case
> the page tree will be traversed n times if there are n pages. This CL
> makes sure the page tree is only traversed once.
>
> Time to load the PDF from the bug below in chrome official build:
> Before this CL: around 1 minute 25 seconds
> After this CL: around 4 seconds
>
> BUG=chromium:638513
>
> Committed: https://pdfium.googlesource.com/pdfium/+/d3a2009d75eac3cda442f545ef0865afae7b35cf
TBR=tsepez@chromium.org,weili@chromium.org,thestig@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2461063003
|
|
Review-Url: https://codereview.chromium.org/2450183003
|
|
Try 2: main fix was recursively popping elements from the stack. Since
the Traverse method can be called on non-root nodes from GetPage(), we
have to make sure to properly update the parents.
Try 1 at https://codereview.chromium.org/2414423002/
In our current implementation of CPDF_Document::GetPage, we traverse
the PDF page tree until we find the index we are looking for. This is
slow when we do calls GetPage(0), GetPage(1), ... since in this case
the page tree will be traversed n times if there are n pages. This CL
makes sure the page tree is only traversed once.
Time to load the PDF from the bug below in chrome official build:
Before this CL: around 1 minute 25 seconds
After this CL: around 4 seconds
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2442403002
|
|
Found by winxfa bot when fx_bool defined to bool.
Review-Url: https://codereview.chromium.org/2449293002
|
|
It's been troubling for some time that an IFX_FileStream might
actually be an in-memory buffer with no backing file.
Review-Url: https://codereview.chromium.org/2443723002
|
|
The CPDF_Document does not own its root dictionary, so add ownership in
CPDF_TestDocumentForPages, using ReleaseDeleter because the dictionary
cannot be deleted.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/2445753002 .
|
|
Added a nontrivial page tree and a test that pages are being fetched
properly, both when requested in order and in reverse order. This will
help prevent introducing bugs while changing the way the page tree is
processed.
BUG=chromium:638513
Review-Url: https://chromiumcodereview.appspot.com/2435783006
|
|
Review-Url: https://chromiumcodereview.appspot.com/2424933002
|
|
https://codereview.chromium.org/2437773003/ )
Reason for revert:
CPDF_DataAvail::IsPageAvail is causing crashes.
BUG=chromium:658168, chromium:658170
Original issue's description:
> Fix loading page using hint tables.
>
> When linearized document have hint table,
> The FPDFAvail_IsPageAvail return true, but
> FPDF_LoadPage return nullptr, for non first pages.
>
> This happens, bacause document not use hint tables, to load page.
>
> To fix this, I force save the page's ObjNum in document.
>
> R=npm, dsinclair
>
> Committed: https://pdfium.googlesource.com/pdfium/+/ef38283688c1ee7c08bcf4204cfb78e09c039782
TBR=dsinclair@chromium.org,tsepez@chromium.org,thestig@chromium.org,art-snake@yandex-team.ru
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://chromiumcodereview.appspot.com/2442663005
|
|
When linearized document have hint table,
The FPDFAvail_IsPageAvail return true, but
FPDF_LoadPage return nullptr, for non first pages.
This happens, bacause document not use hint tables, to load page.
To fix this, I force save the page's ObjNum in document.
R=npm, dsinclair
Review-Url: https://chromiumcodereview.appspot.com/2437773003
|
|
id:60001 of https://codereview.chromium.org/2414423002/ )
Reason for revert:
Possible cause of crbug.com/657897 reverting to find out.
BUG=657897
Original issue's description:
> Traverse PDF page tree only once in CPDF_Document
>
> In our current implementation of CPDF_Document::GetPage, we traverse
> the PDF page tree until we find the index we are looking for. This is
> slow when we do calls GetPage(0), GetPage(1), ... since in this case
> the page tree will be traversed n times if there are n pages. This CL
> makes sure the page tree is only traversed once.
>
> Time to load the PDF from the bug below in chrome official build:
> Before this CL: 1 minute 40 seconds
> After this CL: 5 seconds
>
> BUG=chromium:638513
>
> Committed: https://pdfium.googlesource.com/pdfium/+/7c29e27dae139a205755c1a29b7f3ac8b36ec0da
TBR=thestig@chromium.org,tsepez@chromium.org,npm@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:638513
Review-Url: https://chromiumcodereview.appspot.com/2430313006
|
|
In our current implementation of CPDF_Document::GetPage, we traverse
the PDF page tree until we find the index we are looking for. This is
slow when we do calls GetPage(0), GetPage(1), ... since in this case
the page tree will be traversed n times if there are n pages. This CL
makes sure the page tree is only traversed once.
Time to load the PDF from the bug below in chrome official build:
Before this CL: 1 minute 40 seconds
After this CL: 5 seconds
BUG=chromium:638513
Review-Url: https://codereview.chromium.org/2414423002
|
|
This reverts commit 1d023881cd53485303c0fcc0b5878e700dc470fd.
Reason for revert -- fuzzers hit issues.
TBR=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2425783002
|
|
This reverts commit 3ba098595ae56b64eacc0c25ab76b89a4d78d920.
TBR=thestig@chromium.org,weili@chromium.org
Review URL: https://codereview.chromium.org/2424533003 .
|
|
Doing so highlights a few places where ownership is dubious.
Add convenience functions to return an unowned reference to
a newly-created indirect object.
Review-Url: https://codereview.chromium.org/2419173002
|
|
This tweaks the implementation while leaving the API the
same. The API change is more disruptive, so break this
part off first.
Review-Url: https://codereview.chromium.org/2385293002
|
|
Introduce the UniqueDictionary typedef and friends, to allow
moving to unique_ptrs before the Release() deleter issue is
fully resolved. This will go away down the road.
Review-Url: https://codereview.chromium.org/2420743002
|
|
Small step before making CPDF_Image stream ownership saner.
Review-Url: https://codereview.chromium.org/2416733002
|
|
They won't work with std::unique_ptr down the road, so replace
with std::vector.
Review-Url: https://codereview.chromium.org/2411703003
|
|
Prevent having to remember what an object number of 0 implies.
Review-Url: https://codereview.chromium.org/2412673002
|
|
Review-Url: https://codereview.chromium.org/2409283002
|
|
Ditto with the other ToXXX functions to CPDF_xxx.h.
Shortly, we will want to introduce another variant:
inline std::unique_ptr<CPDF_String> ToString(
std::unique_ptr<CPDF_Object>);
This will require that CPDF_String be complete which is
not the case in the CPDF_Object.h header. Rather than
dragging all the other .h's into it, move these to the
subclass headers. That way, these will be together
when the new form is added.
Review-Url: https://codereview.chromium.org/2406033002
|
|
Split this off so that we don't keep losing this when
the assert is reverted again.
Review-Url: https://codereview.chromium.org/2401423005
|
|
Avoid an assert which previously could only be overcome
by removing/re-inserting.
Back-fill a unit test for the equivalent Array method.
BUG=654387
Review-Url: https://codereview.chromium.org/2403143002
|
|
This reverts commit b69a98cf50537130f88ce3a799117f2ca8353ac5.
Reason for revert: crashes on mac.
BUG=654387
TBR=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2410483002
|
|
- Remove some unused stuff from pageint.h.
- Replace some FX_BOOL with bool in pageint.h, and related.
- Replace some "protected" with "private" in pageint.h.
- Move 2 methods into namespace in fpdf_page_parser_old.cpp.
Review-Url: https://codereview.chromium.org/2399573002
|
|
This reverts commit b73c99335bfbd158ad16dd59c9c52396ffd2b54b.
TBR=thestig@chromium.org
Review-Url: https://codereview.chromium.org/2393783004
|
|
This avoids a re-assignment that can otherwise cause a later fault.
BUG=pdfium:607
Review-Url: https://codereview.chromium.org/2393953002
|
|
FX_BOOL can be replaced by bool. Also replaced in a couple other places
so that Winbots pass.
Review-Url: https://codereview.chromium.org/2395803002
|
|
There's no way to take ownership back from the CPDF_Array
without deleting the object, so add a new primitive to make
elements become indirect rather than manipulating them
outside the class.
This should solve the ASSERT(objnum == 0) issue that
blocked the previous roll.
Review-Url: https://codereview.chromium.org/2391883003
|