| Age | Commit message (Collapse) | Author |
|---|
|
Original Review URL: https://codereview.chromium.org/965423004
TBR=thestig@chromium.org
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/976033005
|
|
This provides no benefit, and reduces transparency.
Along the way:
Kill off some unused/commented-out code.
Return void where a bool return doesn't make sense.
Remove a pointless template type.
Remove now unused constants and types.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/971033002
|
|
This implements the previously unimplemented JS_Error() function.
Along the way:
- fix some IWYU when the include order in global.cpp was perturbed.
- remove some uses of JS_ErrorString, to increase transparency.
- use vp.IsSetting() in place of !vp.IsGetting() for clarity.
- specify an error string on several error return paths.
- add an error string for writing readonly properties.
- rename an error string constant to reflect the actual message.
- replace calls to variadic Format() with a function doing string appends.
- remove unused JS_GetClassName()
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/963193003
|
|
Along the way, I noticed that one of these is used in a header file
that isn't included anywhere and describes no actual code (JS_Console.h).
Also add missing header guards, and IWYU to resources.h
Also move a static function from a header to the new resources.cpp file.
Also fix the grammar on some of the error messages. Most of these
appear to be JS error messages destined for a JS error handler or (someday)
a console (which can remain in english), and oddly, some appear to be about
failed form validation, which smells user-facing.
Also check that the message makes sense for the point the C++ code
wants to use it, and reword accordingly.
As it turns out, these currently don't make it back to JS due to the
unimplemented JS_Error() function; this is an enabling step towards
implementing it.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/955273003
|
|
Re-work of original CL at:
https://codereview.chromium.org/933043002/
Much of the IFXJS interface appears completely unused, so
Kill off unused IFXJS interface methods. The code itself
appears incomplete against all of the objects present
in the paths that actually do register objects with JS.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/954923004
|
|
No functional changes, just tidying some stray characters,
plus kill trailing whitespace while we're at it.
TBR=thestig@chromium.org
BUG=https://code.google.com/p/pdfium/issues/detail?id=123
Review URL: https://codereview.chromium.org/953143002
|
|
Continuation of effort now that a test case is present on origin/master.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/945623002
|
|
This allows us to step through the JS bindings code with the
debugger, which I could not do (but wanted to) the other day.
In the process, get rid of some else after returns, and one
unreachable code path.
I also get rid of some tracing macros that we would never
use for the sake of clarity, and some plain unused
definitions.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/908033002
|
|
This is a purely mechanical change, no new functionality.
- Expand some macros which were merely a short-cut to save
typing but reduced transparency.
- Put GET_VALUE_TYPE() implementation into a .cpp file.
This is a portion of the patch from issue 908033002 at
patchset 40001 (http://crrev.com/908033002#ps40001)
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/927263003
|
|
Note that this work was done opposite the usual branch order, because I
didn't want to kill things in master that turned out to be in use in XFA.
Original Review URL: https://codereview.chromium.org/883393007
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/903893002
|
|
This is similar to how we initialize ICU for V8 inside PDFium.
BUG=455399
R=wfh@chromium.org
Review URL: https://codereview.chromium.org/897973002
|
|
Original Review URL: https://codereview.chromium.org/878333003
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/884873002
|
|
Need to have return value -1 indicating insufficient buffer.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/862163002
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/834703002
|
|
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
|
|
m_sTimeMap is a global variable with a constructor and destructor, which
is not allowed. This change moves it to a function with a static pointer
so that it is constructed on demand and then leaked, thus avoiding
having startup and shutdown code.
This also fixes a worrisome bug caused by having m_sTimeMap defined in
a header file. Because m_sTimeMap was defined (and marked as static) in
a header file there were fifteen separate copies of it, one for each
source file which included the header file. This could easily lead to
bugs because a timer that was added from one source file would be
invisible to other source files.
Each instance of m_sTimeMap added four entries to the
dump-static-initializers.py report, for a total of sixty, so this fix
significantly cleans up that report.
BUG=441899
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/831903002
|
|
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
|
|
FX_ArraySize macro.
pdfium has numerous places where the number of elements in an array is
calculated with expressions like:
sizeof(cFormats)/sizeof(FX_LPCWSTR)
This is suboptimal because it is verbose, it is easy to get wrong, and
it cannot be determined through casual inspection whether the code is
correct. It will give incorrect results if cFormats is a pointer instead
of an array and it will give incorrect results if FX_LPCWSTR is not the
type of the array elements.
The FX_WSTRC macro in fx_string.h which I fixed was particularly scary
because it would silently misbehave if passed a pointer.
The FX_ArraySize macro which I have added and started using (taken from
arraysize in v8's macros.h) is easier to use and will always give correct
results. If passed a pointer it will fail to compile.
For this change I only fixed instances of sizeof(FX_LPCWSTR). There
appear to be about 150 other places in the pdfium code that could
benefit from using FX_ArraySize.
R=bo_xu@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/729293003
|
|
Since casts to FX_LPCWSTR have been shown to hide bugs I tried removing
more of them, targeting those places where a cast was used to force a
conversion from CFX_WideString to FX_LPCWSTR, replacing these casts with
calls to the newly added .c_str() function. This revealed two places
where the cast was hiding a bug -- where ->c_str() was required instead!
This removes ~33 FX_LPCWSTR casts and there are ~31 left, many of which
will go away in some future change.
Also includes this change:
Removing unnecessary casts from wchar_t* to wchar_t*, by various names.
Original patch from Bruce Dawson(brucedawson@chromium.org)
R=bo_xu@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/733693003
|
|
Remove casts that merely cast from wchar_t* to wchar_t*. Sometimes the
types or casts are FX_LPCWSTR but the idea is the same. Excess casts
can (and have) hidden bugs so removing these may prevent future problems.
Original patch from Bruce Dawson(brucedawson@chromium.org)
R=bo_xu@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/730993002
|
|
Complementary patch in chromium is in https://codereview.chromium.org/711553003
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/700373006
|
|
found by /analyze on some error paths
Warning from /analyze was:
src\third_party\pdfium\fpdfsdk\include\fsdk_mgr.h(96) : warning C6001: Using uninitialized memory 'fxtime'.
Other error paths can also lead to reading from an uninitialized _FX_SYSTEMTIME object.
Code-gen for the constructor is small enough (four writes of zeroed EAX with VC++, less with gcc) to make putting the constructor in a .cc file unnecessary.
Approval of in-class member initialization would make this fix simpler but that has not quite been approved yet.
BUG=https://code.google.com/p/pdfium/issues/detail?id=70
BUG=427616
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/692533005
|
|
BUG=425129
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/688303003
|
|
BUG=pdfium-52
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/623893003
|
|
BUG=410326
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/594403003
|
|
Security handler revision number is needed to interpret file permission.
BUG=None
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/589813002
|
|
BUG=chromium:395832
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/478353002
|
|
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.
R=jam@chromium.org, jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/454983003
|
|
BUG=pdfium:28
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/472563002
|
|
This has no ill-effect at present, but may be distracting when viewing the file
since it just looks wrong.
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/461933003
|
|
Edge closer to the goal of building PDFium with the chromium_code
configuration.
BUG=https://code.google.com/p/pdfium/issues/detail?id=29
R=bo_xu@foxitsoftware.com, thakis@chromium.org
Review URL: https://codereview.chromium.org/441763002
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
This change adds the support to extract "NumCopies", "PrintPageRange", "Duplex" viewer preferences for printing.
BUG=169120
R=bo_xu@foxitsoftware.com, vitalybuka@chromium.org
Review URL: https://codereview.chromium.org/345123002
|
|
This contains fixes for the following sorts of issues:
* Nonstandard extension: unnamed struct/union
This also changes the signature of FPDF_FillRect() to enable the cleanest
possible changes in https://codereview.chromium.org/372273005 .
BUG=81439
TEST=none
Original patch by Peter Kasting <pkasting@chromium.org>
Original code review: https://codereview.chromium.org/376003003/
R=pkasting@chromium.org
Review URL: https://codereview.chromium.org/377353002
|
|
Fixes for re-enabling more MSVC level 4 warnings: pdfium/ edition
BUG=81439
TBR=pkasting@chromium.org
Review URL: https://codereview.chromium.org/376043003
|
|
This contains fixes for the following sorts of issues:
* Nonstandard extension: unnamed struct/union
This also changes the signature of FPDF_FillRect() to enable the cleanest
possible changes in https://codereview.chromium.org/372273005 .
BUG=81439
TEST=none
Original patch by Peter Kasting <pkasting@chromium.org>
Original code review: https://codereview.chromium.org/376003003/
R=pkasting@chromium.org
Review URL: https://codereview.chromium.org/372383004
|
|
BUG=382639
R=mdempsky@chromium.org
Review URL: https://codereview.chromium.org/354673002
|
|
MSVC lexes L#macro_arg as a single wide string literal token, but
Clang and other C/C++ compliant lexers do not. There was already
a workaround to use implicit string concatenation for GCC, but there's
a simpler solution of token pasting the L onto the stringized macro
argument with 'L###macro_arg'. This works with Clang, GCC, and MSVC.
R=jun_fang@foxitsoftware.com, jam@chromium.org
BUG=82385
Original patch by Reid Kleckner <rnk@chromium.org>
Review URL: https://codereview.chromium.org/345643002
|
|
R=jam@chromium.org
Review URL: https://codereview.chromium.org/336563004
|
