Age | Commit message (Collapse) | Author |
|
BUG=382988
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/430733004
|
|
Patch from jschuh@chromium.org.
BUG=pdfium:31
TBR=jschuh@chromium.org,thakis@chromium.org
Review URL: https://codereview.chromium.org/438843003
|
|
This reverts commit 4923e3cfbc2b617614858c427fa87a8c67aca784.
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.
BUG=pdfium:28,pdfium:31,chromium:354261
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/432243002
|
|
Goes with https://codereview.chromium.org/431803003/
R=jam@chromium.org
BUG=chromium:354261
Review URL: https://codereview.chromium.org/426153007
|
|
Added by https://codereview.chromium.org/292313014/ but causes
annoying warnings on Windows. Just don't add CRLFs.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/430043002
|
|
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/417263008
|
|
No intended behavior change.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/436483002
|
|
It's unused, and it caused a warning about CPDFSDK_Widget::ResetAppearance()
failing to override it (since these two unrelated methods had the same name).
No intended behavior change.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/429483004
|
|
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).
BUG=395636
R=vitalybuka@chromium.org
Review URL: https://codereview.chromium.org/432543002
|
|
BUG=387854
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/372453005
|
|
No intended behavior change.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/426763003
|
|
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/427353003
|
|
No intended behavior change.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/426763004
|
|
BUG=391929
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/419693003
|
|
There are many warnings that look like:
error: 'CPWL_RadioButton::OnChar' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
virtual FX_BOOL OnChar(FX_WORD nChar);
^
note: hidden overloaded virtual function 'CPWL_Wnd::OnChar' declared here: different number of parameters (2 vs 1)
virtual FX_BOOL OnChar(FX_WORD nChar, FX_DWORD nFlag);
^
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.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/416383004
|
|
fsdk_baseform.h:63:19: error: 'CPDFSDK_Widget::GetLayoutOrder' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
virtual int GetLayoutOrder() {return 2;}
^
fsdk_baseannot.h:70:18: note: hidden overloaded virtual function 'CPDFSDK_Annot::GetLayoutOrder' declared here: different qualifiers (const vs none)
virtual int GetLayoutOrder() const { return 5; }
^
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.
BUG=pdfium:29
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/427173002
|
|
fpdfview.cpp
BUG=397258
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/419063002
|
|
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.
BUG=392956
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/423233002
|
|
BUG=None
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/420793004
|
|
Follow-up from https://codereview.chromium.org/424883002/
- Remove some stray whitespace.
- Fix "else after return".
- Remove unused swResponse local.
- Treat unexpectedly large responses as errors.
BUG=
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/423953002
|
|
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
|
|
Found by clang's -Wunused-variable, -Wunused-function, -Wunused-const-variable.
BUG=none
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/404653005
|
|
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.
So just remove the 'inline'.
BUG=none
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/409253004
|
|
BUG=pdfium:19
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/403163002
|
|
BUG=382667
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/322333002
|
|
The |nGrowBy| argument to |SetSize| was always -1, which caused the
effective m_nGrowBy value to always be its default value: 0. So it was not
needed, and was cluttering up the logic.
BUG=384662
Check for integer overflow in CFX_BasicArray.
BUG=384662
R=bo_xu@foxitsoftware.com, rsesek@chromium.org
Review URL: https://codereview.chromium.org/415803002
|
|
BUG=384662
R=bo_xu@foxitsoftware.com, rsesek@chromium.org
Review URL: https://codereview.chromium.org/411033003
|
|
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=pdfium:26
TBR=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/418463002
|
|
BUG=395266
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/411713003
|
|
BUG=396255
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/407243003
|
|
BUG=179413
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/410073002
|
|
BUG=179413
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/408403002
|
|
BUG=None
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/396173003
|
|
Follow-up to https://codereview.chromium.org/370853002/
BUG=none
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/406683005
|
|
This should be set consistently on all platforms. Ideally, we wouldn't
need exceptions, but for now they're used.
BUG=none (noticed while looking at chromium:82385)
R=jam@chromium.org
Review URL: https://codereview.chromium.org/404803005
|
|
BUG=382667
R=jschuh@chromium.org, jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/390983007
|
|
The function is looking ahead N characters at both its "format" and "value"
strings without validating that accesses are in bounds. Add those validations.
There are also duplicate checks in the else-branches which re-test the inverse
of the if-branch. These are removed for simplicity.
I also tidied some stray whitespace in the function while I was at it.
BUG=393831
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/395303004
|
|
BUG=pdfium_23
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/399233002
|
|
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.
BUG=none
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/370853002
|
|
BUG=260112, 249006, 275281, 354966, 365302, 236952
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/400083002
|
|
This adds the necessary directives to the standalone gyp file.
R=jschuh@chromium.org, jam@chromium.org
BUG=22
Patch from Michael Doppler <m.doppler@gmail.com>.
Review URL: https://codereview.chromium.org/360273002
|
|
It remains to call the PumpMessageLoop() method at a regular interval,
however, since nothing posts to the loop yet, that shouldn't be a
problem.
BUG=25
R=jam@chromium.org
Review URL: https://codereview.chromium.org/374123002
|
|
BUG=376399
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/398163006
|
|
Original patch by Andrey Khalyavin <halyavin@google.com>
BUG=N/A
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/384143002
|
|
It currently doesn't have any build warnings, and this way the
chromium build is guaranteed to stay warning-free after pdfium rolls.
BUG=none
R=jam@chromium.org
Review URL: https://codereview.chromium.org/373643002
|
|
Fixes a warning.
BUG=
TBR=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/395293002
|
|
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.)
No intended behavior change. Fixes this error on the clang/win bot:
..\..\third_party\pdfium\core\src\fxge\win32\fx_win32_device.cpp(207,20) : error(clang): default initialization of an object of const type 'const _FontNameMap [1]'
const _FontNameMap g_GbFontNameMap[1];
^
BUG=chromium:82385
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/369343003
|
|
BUG=386728
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/397803002
|
|
BUG=391470
R=palmer@chromium.org
Review URL: https://codereview.chromium.org/384593002
|