| Age | Commit message (Collapse) | Author |
|---|
|
It would seem that this never merged completely.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1277583002 .
|
|
No behavior change.
Generated by:
find . -name '*.cpp' -o -name '*.h' | \
grep -E -v 'third_party|thirdparties|lpng_v163|tiff_v403' | \
xargs ../../buildtools/mac/clang-format -i
Then manually merged https://codereview.chromium.org/1269223002/
See thread "tabs vs spaces" on pdfium@googlegroups.com for discussion.
BUG=none
|
|
Original Review URL: https://codereview.chromium.org/1235393002 .
(cherry picked from commit fb07e2843dad0774d5842c2b08e7792164efc14a)
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1244503002 .
|
|
There are more CFX_MapPtrTemplate usage on the XFA branch, so it is
not removed.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1181593003.
(cherry picked from commit e8d3691c82d1be805ffdce3329d00313af7ce0ab)
Review URL: https://codereview.chromium.org/1198663004.
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1176333002.
(cherry picked from commit 0ef0de55657db8a83372ad8eb22d84c5893afc4c)
Review URL: https://codereview.chromium.org/1195943005.
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1183483003.
|
|
Nearly automatic merge + re-run script on new files.
Original Review URL: https://codereview.chromium.org/1180593004.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1174303002.
|
|
Original Review URL: https://codereview.chromium.org/1171733003
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1178613002.
|
|
New manual edits in the following to fix compilation:
fx_bmp.h, fx_gif.h, fx_graphics.h
Original Review URL: https://codereview.chromium.org/1169963003
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1170103004
|
|
A second case of casting willy-nilly between unrelated structures
to provide information hiding. Bad Idea. Remove dozens of casts
in the process.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1155273002
|
|
Original Review URL: https://codereview.chromium.org/1160443004
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1162013003
|
|
Original Review URL: https://codereview.chromium.org/1135913002
BUG=pdfium:154
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1136703003
|
|
Orignal Review URL: https://codereview.chromium.org/971033002
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/969203002
|
|
None of these are currently reachable because the IsSafeMode
method always returns true. This, in turn, will let us kill
off some file (as in fopen()) based parsing. That, in turn,
will let us kill of some more now-unreachable code.
In general, we don't want to have unsafe modes.
BUG=https://code.google.com/p/pdfium/issues/detail?id=116
R=jam@chromium.org
Review URL: https://codereview.chromium.org/883393007
|
|
Includes fixes to XFA specific warnings -- benign truncations.
Bug https://code.google.com/p/pdfium/issues/detail?id=104
was filed to track changing types to avoid some truncations.
Resolve all but two VC++ build warnings in pdfium.
pdfium builds on Win32 have about 85 warnings (250 in the XFA
branch, totaling over 480 lines!), mostly from four lines in
a header file and a warning that should be disabled. This
change resolves all but two of them and turns on
warning-as-errors. Bugs have been filed for the two
remaining warnings:
https://code.google.com/p/pdfium/issues/detail?id=100
the 64-bit warnings:
https://code.google.com/p/pdfium/issues/detail?id=101
and the Linux warnings:
https://code.google.com/p/pdfium/issues/detail?id=102
The fix to the double->float truncation bugs will also
improve code-generation.
R=bo_xu@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/792953005
BUG= https://code.google.com/p/pdfium/issues/detail?id=100
Review URL: https://codereview.chromium.org/834413002
|
|
|
|
|
|
BUG=410326
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/594403003
|
|
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
|
|
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=382639
R=mdempsky@chromium.org
Review URL: https://codereview.chromium.org/354673002
|
|
|
|
|
