Age | Commit message (Collapse) | Author |
|
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
|
|
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
|
|
... 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
|
|
Then remove CFX_{Wide,Byte}String::LockBuffer(). Prelude to a vast
simplification. There's an additional copy now in one place, so
shoot me.
BUG=pdfium:144
R=thestig@chromium.org
Committed: https://pdfium.googlesource.com/pdfium/+/ee7412f5aef353e5c6f1a64d0e1708ed926869d9
Committed: https://pdfium.googlesource.com/pdfium/+/5a256ad29483eb2b13e6e2c89fe0f77a9103f68f
Review URL: https://codereview.chromium.org/1053613004
|
|
This reverts commit 5a256ad29483eb2b13e6e2c89fe0f77a9103f68f.
Reason for revert: broke JS tests.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1112673002
|
|
Then remove CFX_{Wide,Byte}String::LockBuffer(). Prelude to a vast
simplification. There's an additional copy now in one place, so
shoot me.
BUG=pdfium:144
R=thestig@chromium.org
Committed: https://pdfium.googlesource.com/pdfium/+/ee7412f5aef353e5c6f1a64d0e1708ed926869d9
Review URL: https://codereview.chromium.org/1053613004
|
|
This reverts commit ee7412f5aef353e5c6f1a64d0e1708ed926869d9.
Reason for revert: VS compile broke.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1106333003
|
|
Then remove CFX_{Wide,Byte}String::LockBuffer(). Prelude to a vast
simplification. There's an additional copy now in one place, so
shoot me.
BUG=pdfium:144
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1053613004
|
|
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
|
|
Part 2 of 4.
R=thestig@chromium.org
TBR=brucedawson@chromium.org
BUG=pdfium:142
Review URL: https://codereview.chromium.org/1099193002
|
|
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
|
|
Part 4 of 4.
BUG=pdfium:142
R=brucedawson@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1084293003
|
|
Part 3 of 4.
BUG=pdfium:142
R=brucedawson@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1099213002
|
|
It's unused.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1098203002
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1096853002
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1084613006
|
|
Replace them with |new| so that we can tell by the presence of FX_NEW
the places that still need to be audited.
R=thestig@google.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/1052553006
|
|
Restores default behavior of new.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1082253003
|
|
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
|
|
Three functions in fx_coordinates.h account for 60% of the warnings
when building with VS 2015, due to variable shadowing. Renaming the
function parameters is safe, resolves the warnings, and reduces
confusion.
R=tsepez@chromium.org
BUG=440500
Review URL: https://codereview.chromium.org/1077083003
|
|
Replaces https://codereview.chromium.org/1062983002/
BUG=469244
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1077903002
|
|
Confirmed manually that:
g++ --std=c++0x -o /dev/null -I. ... -c fx_xxxxx.h
is now error-free for the files in this directory. Also kill
some ifndef's around inclusion since we know this doesn't
provide benefit with modern compilers.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1064433005
|
|
This reverts commit 090d683489bfa3f36f1e2624c310ff9ca5836038.
Symbol appears in files that are not compiled anywhere, it would seem.
Reverting to remove these first.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1001023003
|
|
It's unused, and when the time comes, we'll want to put
pdfium onto a hardened allocator like partitionAlloc anyways.
Along the way, merge adjacent #ifdef __cplusplus blocks,
remove a pointless check for __cplusplus inside a .cpp file,
and remove a redundant cast.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1008483002
|
|
I thought I had done this already, apart from the third-party
libraries, but there were a couple remaining (the third-party
libraries will still call this, they should be tweaked
upstream as needed).
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/999543002
|
|
BUG=449845
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/911293002
|
|
The bstring's read from file is unused.
The load from file paths aren't taken.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/902943003
|
|
Headers in /include directories should be free of implementation details
from third_party. Put the types into a new header outside of /include.
Requires https://codereview.chromium.org/902443003/ before a version containing this patch is rolled into chromium.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/896023003
|
|
This is part of the project to kill off C-style casts in the code base.
Remove implict T* cast operator, and replace potentially unsafe C-style
casts with Get() method.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/889673003
|
|
A suitably corrupted file can cause the parser(s) to repeatedly re-read
sections of the file at increasing parser recursion depth until the
stack is exhausted. There is supposed to be a check for this based upon
the parser "level", but not all call paths pass or update the level as
required.
Much as I hate per-class statics, this introduces one to track the depth
so that the check is enforced no matter how screwy the call path might be
that leads the parser to re-enter itself. This is more palatable than trying
to find all these paths and fix them. We know this is OK since there is
only one thread in here modifying the static.
BUG=451830
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/875263002
|
|
Previously, UTF16LE_Encode take an optional flag to indicate
if the returned byte string has trailing zeros. In fact, no where
needs the flag to be false. So just get rid of it so callers won't
misuse.
The bug is found by https://codereview.chromium.org/837723009
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/860973002
|
|
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
|
|
This fixes a few cut-n-paste errors in the previous version, plus
adds more corner cases. The implementation is fixed to handle a
few of these that failed.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/808553013
|
|
This allows integration with the gtest EXPECT_* macros.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/837843002
|
|
Follow up on https://codereview.chromium.org/733693003
R=brucedawson@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/809993004
|
|
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
|
|
As of the 2013 version VC++ still doesn't support the 'z' size specifier. This makes portable printing of size_t types frustrating. The simplest general solution is to use %u and cast to unsigned. If there was any possibility of the numbers getting larger than 32-bit then we would need better alternatives, but there is not.
This was found through code inspection, through /analyze, and through pdfium_test print this non-helpful message:
Loaded, parsed and rendered zu pages.
Skipped zu bad pages.
I can confirm that the fix works on Windows and it should work identically on mac. This is a follow-on to change 02e6ca4c4f.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/738433003
|
|
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
|
|
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=382988
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/433293002
|
|
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/417263008
|
|
fpdfview.cpp
BUG=397258
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/419063002
|
|
BUG=pdfium:19
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/403163002
|
|
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
|