Age | Commit message (Collapse) | Author |
|
This CL is used for:
1. keeping the same logic as before (the behaviour
of FX_Alloc was changed for OOM).
2. fixing a potential integer overflow.
BUG=N/A
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1126013006
|
|
This avoids unchecked multiplications when computing a size argument
to malloc(). Such an overflow is very scary, and can result in
exploitable bugs.
Along the way, kill off some return checks, since we know this can't
return NULL.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1143663004
|
|
For FlateEncode(), error handling code leaked memory.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1144603002
|
|
Add a FX_TryAlloc() for those few cases where we might need to continue
in face of OOM.
Remove FX_AllocNL() (the context of its use would suggest that NL
means "No Limit"). This is used for some big allocations, so replace
it with TryAlloc(). Large allocations may be worth trying to continue
from, since there are few and they have a large chance of failing.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1128043009
|
|
Also fix a few nits and other errors along the way.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1098583002
|
|
BUG=484002
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1124563002
|
|
BUG=453553
R=thestig@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1093323003
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1084303002
|
|
CFX_Object is a type that implements its own new operators that return
NULL on error. There's no need for this given the |new (std::nothrow)|
syntax; in fact, the current code can only work if there is no activity
in the constructors. This may explain the pervasive lack of
constructors and reliance on Init() methods throughout the codebase.
The activity takes place in fx_memory.h, where FX_NEW is mapped onto
the std::nothrow syntax. The rest is just cleanup.
Down the road, we will simply throw and remove all the error-checking
paths for new objects. Landing this patch first will at least show a
simple path back to the old behaviour without having to re-introduce
CFX_Object should someone want to do so in their own fork.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1088733002
|
|
BUG=476107
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1080893002
|
|
Needed to fix the failed pdfium_unittests on windows. Ironically,
I created these constants so I wouldn't mix up size_t's and off_t's
in these tests, but I didn't apply them consistently.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1036743005
|
|
Build broken on trybot at
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel/builds/66012/steps/compile%20%28with%20patch%29/logs/stdio
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1026843002
|
|
Follow on to https://codereview.chromium.org/990683002/.
This more closely mimics what fseek() actually does, so as
to avoid subtle bugs down the road.
Move the DecodeData struct into a header so the test can
use it, and provide a constructor for it.
Along the way, I added include guards, removed the p_
prefix from some non-pointer vars, fixed some IWYU, and
resolved some signed/unsigned comparison warnings with
careful casting.
BUG=452671
R=jun_fang@foxitsoftware.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/1016203002
|
|
In the process of opj_end_decompress, it will return fail when the end of coding stream is reached. However it returns true in the same scenario implemented in openJPEG. So the final solution is from openJPEG. Return true when the end of coding stream is reached.
BUG=452671
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/990683002
|
|
I thought I had done this already, apart from the third-party
libraries, but there were a couple remaining (the third-party
libraries will still call this, they should be tweaked
upstream as needed).
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/999543002
|
|
Speculative fix since the issue doesn't reproduce locally.
TBR=brettw@chromium.org
Review URL: https://codereview.chromium.org/988883002
|
|
BUG=457493
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/960183004
|
|
It's only used internally. This also avoids errors from the verify_order script when linking PDFium into Chromium
BUG=453844
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/887193002
|
|
BUG=445475
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/837093002
|
|
This is done by explicitly adding a virtual dtor to interface classes,
since the cost is small given that there are already virtual functions.
The exceptions are for classes that have a Release() or Delete() method,
in which case it is non-virtual and protected to indicate that the virtual
class is never the deletion point.
BUG=
R=brucedawson@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/810883005
|
|
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/837533003
|
|
This is a follow up CL on https://codereview.chromium.org/761313004/
BUG=https://code.google.com/p/pdfium/issues/detail?id=93
R=brucedawson@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/828183002
|
|
This reduces rendering time on my test document by over
10 seconds. It is super common for a JBIG2 dictionary to
span multiple pages, so we don't want to decode the same
dictionary over and over again.
Original patch from Jeff Breidenbach (breidenbach@gmail.com)
BUG=https://code.google.com/p/pdfium/issues/detail?id=85
R=bo_xu@foxitsoftware.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/761313004
|
|
QeTable is a 752 byte array that was defined in a header file. This
caused it to be instantiated by the VC++ compiler 12 times, wasting
8,272 bytes of space in the data segment. Because 'const' implies
'static' this did not cause any duplicate symbol errors.
JSCONST_n*HASH are a set of eight variables that are defined in a header
file. This causes them to be replicated 15 times. The variables
themselves are tiny but they are dynamically initialized and this
dynamic initialization code is replicated 15 times.
When tested on pdfium_test.exe the effect of this change is to:
Reduce the .text (code) segment by 3,616 bytes.
Reduce the .rdata section by 8,656 bytes.
Reduce the total binary file size by 13312 bytes.
These are the worst offenders for pdf.dll as shown in:
https://drive.google.com/open?id=1BvubxoA2SU_2e4T5cq7jHTjc1TlT0qOndpIfX3DMeA8&authuser=0
This will also drastically simplify the list of work to be done
for bug 441899 (getting rid of initializers).
BUG=441988
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/802013002
|
|
-remove parameter from FPDF_InitLibrary
-remove a bunch of ifdefs that are unused
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/801913002
|
|
BUG=429139,430566,431288
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/758593002
|
|
BUG=414036, 425151
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/688633003
|
|
BUG=418976, 425150, 414525
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/671943002
|
|
BUG=414089, 414310, 414606
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/670813002
|
|
This patch is supplementary to issue 418881
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/645793007
|
|
This is a re-landing of the changes in https://pdfium.googlesource.com/pdfium/+/6387aff
which were lost during a libopenjpeg library roll.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/661463003
|
|
BUG=418881
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/648823002
|
|
BUG=413375
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/624023003
|
|
BUG=407964, 414182, 413447
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/589243004
|
|
BUG=
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/534363002
|
|
This is code cleanup rather than bug fixing.
The motivation for this was to fix the casts at line 97 of the original file. These are wrong; you cannot correct via casting a function signature mismatch when passing a function as an argument. In theory, there's no reason to believe that the compiler will pass args in the same manner for a function of type (void*, size_t, void*) as for a function of type (void*, size_t, some_struct*). The cast will suppress the compile error, but you can't be assured the call will work as intended. In practice, it does, since the last architecture where a void* had a different representation than a struct* went extinct in the late 80s.
In the functions themselves, note that we currently bail out if srcData->offset >= srcData->src_size, so the expression
bufferLength = (OPJ_SIZE_T)(srcData->src_size - srcData->offset)
will always be > 0. Hence the check
if(bufferLength <= 0)
is pointless, esp. since bufferLength is a signed type and < 0 makes no sense.
The opj_seek_from_memory() has a bool return value, so returning -1 on error doesn't seem reasonable. Change this to TRUE/FALSE, and return false on seek past end.
If we're truly passing readonly data, then perhaps it makes sense to make the write() function always return -1. I didn't do this.
Lastly, I capitalize "DecodeData" so that it looks like a struct, and change its members to be size_t's to avoid casting back and forth.
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/507273003
|
|
There is not strict way to limit invalid value of |Colors| from dictionary. We can make sure |index| does not go out of boundary of row_size.
BUG=407614
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/509993003
|
|
BUG=407476
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/489703004
|
|
BUG=406806
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/503883002
|
|
(patchset #1 of https://codereview.chromium.org/493163003/)
Reason for revert:
Needs to address comments before landing
Original issue's description:
> Use number of components from ICC profile and alternate color space
>
> BUG=406806
>
> Committed: https://pdfium.googlesource.com/pdfium/+/be83103
TBR=tsepez@chromium.org,jun_fang@foxitsoftware.com
NOTREECHECKS=true
NOTRY=true
BUG=406806
Review URL: https://codereview.chromium.org/504883003
|
|
BUG=406806
Review URL: https://codereview.chromium.org/493163003
|
|
BUG=393602
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/466153005
|
|
BUG=pdfium:28
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/472563002
|
|
BUG=387811
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/437483004
|
|
No intended behavior change.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/426763003
|
|
No intended behavior change.
- 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.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/429593005
|
|
Since the land of https://pdfium.googlesource.com/pdfium/+/3522876d5291922ddc62bf1b70d02743b0850673, memory is assured to be 16 byte aligned. So no need to do this check.
Plus, the removed code was causing bug in M36: https://code.google.com/p/pdfium/issues/detail?id=27.
BUG=None
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/418563002
|
|
BUG=387826
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/387273002
|
|
BUG=387843
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/380293002
|
|
BUG=
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/372473003
|