Age | Commit message (Collapse) | Author |
|
It's redundant nowadays to provide our own equivalents, now
that this is done for us by the system header.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1177483002
|
|
- include system headers first and alphabetize.
- remove unsupported FX_WIN32_MOBILE symbol.
- actually define a FX_WIN64 symbol and make consistent.
- use final/override, not FX_FINAL.
- let stdint.h resolve FX_WORDSIZE concerns.
- unused FX_ERR and FX_SUCCESS() macros.
- unused FX_LSB_FIRST macro.
- outline FX type deprecation plan.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1169963003
|
|
Leaks can happen in several places. For this particular bug, it happens
when there is a colorspace component count mismatch.
BUG=497191
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1153633009
|
|
Small bit of OCD here, since this file is included cross-library
(i.e. from fpdfsk), it can't be in src/. In other words, the
following should be empty:
grep -R 'include.*core/src/' fpdfsdk
Fix some IWYU in it at the same time.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1147353006
|
|
Some are simply never defined. Some are never instantiated. Some have
paths that are never reached.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1168503003
|
|
Its fine to program to interfaces, but since the sole concrete implementation
is in the same header as the interface, the code is bypassing it anyways. We
can de-virtualize some things along the way, and remove two non-existent
function prototypes from one of the headers.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1158053003
|
|
Get rid of leading _CAPITAL identifiers.
A large number of these didn't actually match the filename.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1160443004
|
|
Two "set but unused", one of which is surely an artifact from
copying code around, and the other which ought to be used for
the sake of clarity.
Two are unknown "optimize" pragmas, remove them since the code
has been shipped for years on other platforms under full optimization.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1148353002
|
|
Fixes the ordering of some assignments broken when converting to checked
numerics in CFX_PathData::AddPointCount().
Original Review URL: https://codereview.chromium.org/1142713005
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1135893008
|
|
This reverts commit eb6527763171cdb4b0fbfea5a20d691f4d67b660.
Reason for revert: broke javascript tests.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1145843005
|
|
This permits some functions to become void's since
they, in turn, can't fail.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1142713005
|
|
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
|
|
Also change EmbedderTest::TearDown() to match the destruction order in
Chromium's PDF code.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1138143003
|
|
There isn't much point in having macros that obscure obvious
language features.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1135273004
|
|
Also fix typos and remove trailing spaces/tabs.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1141123002
|
|
These are the only files that embedders of PDFium should be including.
They are entirely self-contained, and compile cleanly against -Wall so
as to not offend the code that may include them.
Having done this, we can see that chromium is pulling in two additional
files from the fpdfsdk/include/pdfwindow directory, which is not guaranteed
to work.
A few files are renamed, adding an "_" to make the names consistent.
The exception is fpdfview, which is doc'd as such in the doc.
Naturally, paths will need updating in a handful of files in chrome
when this rolls in.
BUG=pdfium:154
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1135913002
|
|
Also fix a few nits and other errors along the way.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1098583002
|
|
BUG=pdfium:153
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1124043003
|
|
Failure to check document-controlled value before using it.
BUG=481363
R=palmer@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1110653002
|
|
This involves adding some explicit c_str() calls. Doing so flagged
PDF_EncodeText() and FindOptionValue() as having suboptimal signatures, in
that we are often throwing away a perfectly fine length and recomputing it.
There are still some platform-specific code that needs the operator.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1101933003
|
|
This reverts commit 15a62973b9b89c3e229cc0ab501c45967f91b325.
Reason for revert: broke build on windows, mac. I must have missed
some platform-specific conversions.
TBR=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1108883002
|
|
This involves adding some explicit c_str() calls. Doing so flagged
PDF_EncodeText() and FindOptionValue() as having suboptimal signatures, in
that we are often throwing away a perfectly fine length and recomputing it.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1101933003
|
|
BUG=467392
R=thestig@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1064713008
|
|
Removing the implicit cast operator forces a build breakage should we
use ByteStringC in STL containers. Adding an operator< restores correct
behaviour. Adding an operator[] avoids re-writing some code to call
GetPtr() prior to array indexing.
Part 1 of 4.
R=thestig@chromium.org
TBR=brucedawson@chromium.org
BUG=pdfium:142.
Review URL: https://codereview.chromium.org/1090303003
|
|
This regressed in commit 3f41851 due to shadow variables.
BUG=478164
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1101443004
|
|
BUG=pdfium:140
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1093213002
|
|
This can't change for the life of the object, so tidy up some wild uses
throughout the code. Also kill pointless Initialize() method.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1060813003
|
|
- Check bounds when accessing array.
- Remove potential memory leak.
- Merge duplicate code.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1094763002
|
|
Very few places where a change is required, but remove FX_NEW to show
they've been audited.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1075953004
|
|
BUG=380476
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1061013003
|
|
Note: Landed on XFA first by mistake.
Original review: https://codereview.chromium.org/1085963002/
TBR=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1090463002
|
|
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
|
|
Add a check to make sure offset is less than the size of string in the function of GetNextChar().
BUG=471651
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1067073003
|
|
A stack overflow was triggered by checked_cast due to
invalid index in pdf files like 'Index[45 -1661]'.
BUG=473400
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1054303005
|
|
The initialization sequence becomes more complicated as v8 evolves
and when we move to XFA (where pdfium_unittests are currently broken).
Centralize this initialization in a few places, like the embedder_test
framework and the pdfium_test binary, and convert tests that require
it into embedder_tests rather than unit_tests.
Change on master first before moving to XFA.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1071343002
|
|
There is not a code page (CP) used for converting unicode to mutli-bytes
if the coding scheme is CID coding. Only return 0 if CID can't be retrieved.
The difference on Windows and other platforms should be the function used
for converting rather than others.
BUG=466790
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1074653002
|
|
BUG=N/A
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1059233005
|
|
Adds a comment and changes some whitespace.
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1059373002
|
|
BUG=N/A
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1057383002
|
|
When there is a wrong keyword like '??ze' in the dictionary
of the trailer, PDFium can't recognize it and aborts further
parsing. After this change, PDFium continues even it can't
get the right size at this moment. It will rebuild the cross
reference table later since the size of the table is missing.
BUG=459580
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1055323003
|
|
space is used"
This reverts commit 5a0e504d53195892458d819e52c62bea0c710bd5.
Original review URL https://codereview.chromium.org/1009513003
Reason for revert: New "corpus" tests show that this is no longer rendering some images. See, e.g. http://chromegw/i/client.pdfium/builders/linux/builds/144/steps/corpus%20tests/logs/stdio for those that diff'd.
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1016823003
|
|
There are two issues in this bug.
One is that JP2 image is not displayed because it aborts loading Jpx bitmap when the number of components in color space is different with that one in JPX images. I found that the number of components in color space isn't updated after it's initialized. For index color space, the component shall inherit from its base color space.
The second issue is that displayed color is not correct after I fixed the first issue. The root cause is that sRGB is used in JPX image, it doesn't need to map from index to RGB again.
BUG=464215
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1009513003
|
|
BUG=382661
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1007643002
|
|
As we remove flate encoded sections from test cases (to
promote clarity), we should first have a simple unit test
for the underlying functionality.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/845313006
|
|
BUG=453723
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/892553002
|
|
This issue was introduced in https://codereview.chromium.org/886953002/.
BUG=454280
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/869343008
|
|
Follow-on from https://codereview.chromium.org/911293002/
Currently, all the subclass constructors are reaching up
into the parent class to do this. Fix this, just because.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/880233005
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/885223004
|
|
BUG=pdfium:29
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/891113002
|