Age | Commit message (Collapse) | Author |
|
Integer overflow in CJBig2_Image::expand.
It causes the size of reallocated is not
expected.
BUG=483981
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1131023008
|
|
The opj_j2k_copy_default_tcp_and_create_tcp() function memcpy's a top-level
struct, and then replaces pointers to memory owned by the original struct
with new blocks of memory. Unfortunately, an early return can leave the
copy with pointers to memory it doesn't own, which causes problems when
cleaning up the partially-initialized struct.
The referenced bug is triggered when we get a return at original
line 7969 or 7385 due to OOM.
Moral of the story: creating a "copy constructor" equivalent
based on memcpy() instead of copying field by field for structs
containing pointers is usually a bad idea.
BUG=486538
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1138033007
|
|
those types are just aliases, and we should consistently use the new version
R=tsepez@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1138823004
|
|
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
|
|
R=tsepez@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1133333005
|
|
In most cases, we just CHECK() that no exception was thrown. Previously,
we'd just crash.
Ideally, this should all be fixed and the system should cope with those
exceptions, but that's beyond this CL.
R=tsepez@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1126203010
|
|
For FlateEncode(), error handling code leaked memory.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1144603002
|
|
Triggering allocation failure can be ... slow. See
http://build.chromium.org/p/client.pdfium/builders/win/builds/126
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1142463005
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1137933004
|
|
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
|
|
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
|
|
There isn't much point in having macros that obscure obvious
language features.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1135273004
|
|
If ConcatCopy somehow gets a zero nNewlen, it returns early, without
allocating a new m_Data. ConcatInPlace then frees the old one, leaving
m_Data dangling.
Also be concerned about the multiplication in the widestring version.
So use wmemcpy and let the library cope with it.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1130763007
|
|
Also fix typos and remove trailing spaces/tabs.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1141123002
|
|
This is a precondition for someday combining Byte/Wide strings
via templates.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1142533002
|
|
BUG=471991
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1141613002
|
|
Phantom handles allow for freeing objects with one pass of GC. However,
this means that by the time the callback is invoked, the v8 object already
does no longer exist. To avoid accidential access to the dead object, there
are now two callbacks, where the first must only reset the handle, and the
second does the clean-up work.
R=tsepez@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1129253004
|
|
- Make include guards consistent with standard and filenames.
- Remove stray semicolon folowing extern "C" section close-brace.
- Untabify.
- Delete trailing whitespace.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1128003005
|
|
Also corrects some ASSERT_'s to EXPECT_'s in the test.
BUG=pdfium:160
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1141763002
|
|
The internal fields are scanned by the garbage collector, so they can't contain arbitrary data. However, aligned pointers are supported by the V8 GC, so the V8
API allows for setting a pointer directly instead of wrapping it in an External
container.
Not only is this faster, but it's also required for the new v8::Global API which
I'm going to update to in a follow-up patch.
R=tsepez@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1139853003
|
|
This involves adding some missing extern "C" { } declarations,
using FPDF_ types instead of C++ types, and converting pass
by reference arguments into pointers.
Test this using fpdfview_embedertest for simplicity.
BUG=pdfium:158
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1130843003
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1140833002
|
|
The checked conversion can be re-enabled now that there is a public
API free of private headers like this one.
This reverts commit 6661fd4c26106cd530d187b36f29be7e5c98b70f.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1133323003
|
|
PDFium side of fix to make chromium free of private header
includes. This moves the one snippet of contaminating code
from chrome to PDFium itself.
BUG=486818
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1126283004
|
|
This is currently blocking a PDFium roll in chrome, see
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presubmit/builds/62816/steps/presubmit/logs/stdio
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1136533003
|
|
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
|
|
... rather than redundantly declaring them in several .cpp files, and
hoping that the linker lines things up for you.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1128193004
|
|
This is a fix to hide pdfium's safe_conversions.h from the
higher-level callers.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1132163002
|
|
BUG=pdfium:114
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1124423006
|
|
- fread() returns the number of items read.
- fix a memory leak in error handling.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1135713004
|
|
Also fix a few nits and other errors along the way.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1098583002
|
|
This mimics the std:: behaviour.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1130053003
|
|
Reason for revert: No longer needed in face of 9ea57a43faea
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1122423006
|
|
BUG=pdfium:153
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1124043003
|
|
This gets included in chromium's pdfium_engine.cc, and thus must pass a
higher error level. There's probably a follow-up to check why the FPDF_ api
doesn't insulate chromium from this file.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1127043004
|
|
BUG=484002
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1124563002
|
|
These flags are unused in Chromium, but are needed for the Cloud Print
conversion process, which takes PDF and produces a raster for low-end
printers. Certain low-end printers (e.g., B&W laser printers) will
turn anti-aliased text into a mess. The existing printing flag isn't
sufficient, as other kinds of printers will still want some kinds of
anti-aliasing to occur for best results.
BUG=482253
TEST=none
R=vitalybuka@chromium.org
Review URL: https://codereview.chromium.org/1115513002
Patch from Scott Byer <scottbyer@chromium.org>.
|
|
Separate out the overload when the length is not known, and be sure that
strlen() call is in the header so that strlen("foo") => 3 (since many
compilers support this optimization).
Also delete some unused types.
BUG=pdfium:151
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1117263004
|
|
Part two. Fix same issue in wide strings as in their bytestring
counterparts.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1127753002
|
|
I spent at least 2 minutes grep'ing for a class or struct (on the other
branch) that was delcared using this.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1129433002
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1125703004
|
|
Continuation of https://codereview.chromium.org/1122573002
Applies similar test to immutable versions of strings.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1118973005
|
|
... and there are a few inconsistencies which we can now fix. Also add a
comment about why these strings aren't headed for the dust-bin long term.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1122573002
|
|
Also prevent theoretical roll-over where long smaller than intptr_t.
See bug for discussion.
BUG=pdfium:149
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1117413002
|
|
(Also makes the calculation robust in face of changes to the header).
BUG=pdfium:149
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1118983003
|
|
As part of the migration from GYP->GN, we want to make sure that we
can track when new targets are added to either the GYP or GN builds
and that we are building everything we expect to build.
In GN, unlike GYP, if a build file gets referenced from other files,
building 'all' will cause every target to be built in it. This means in
particular, that we can end up trying to build targets that are not
necessarily intended to be visible to the rest of the build. To get
around this, any target that is defined but hidden (like 'pdfium_unittests',
) should still be visible to a top-level target called
"//:gn_visibility".
R=tsepez@chromium.org, brettw@chromium.org
BUG=461019
Review URL: https://codereview.chromium.org/1120183002
|
|
Follow-on to https://codereview.chromium.org/1120703003/
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1112423003
|
|
Given the representation of StringData, it seems sub-optimal not to be doing this.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1120703003
|
|
This allows PDFium to work with current V8, so unpin v8 in the
pdfium DEPS file.
(I also re-ordered one field in CJS_Runtime, just to put two bools
together (may pack tighter), and to put all the v8 stuff together).
BUG=pdfium:146
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1118043002
|