summaryrefslogtreecommitdiff
path: root/core/src/fxcrt/extension.h
AgeCommit message (Collapse)Author
2014-08-13Add FX_OVERRIDE and use it for virtual functions of FX_FINAL classes.Tom Sepez
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
2014-08-07Change '>=' back to '>' in extension.h due to bad fixchromium/2122chromium/2121chromium/2120chromium/2119chromium/2118Jun Fang
BUG=400662 R=tsepez@chromium.org Review URL: https://codereview.chromium.org/445303002
2014-07-31Correct the names of the FX_SAFE_* typedefs.Chris Palmer
R=jun_fang@foxitsoftware.com Review URL: https://codereview.chromium.org/417263008
2014-07-30Fix the potential integer overflow from 'offset+size' in extension.h and ↵JUN FANG
fpdfview.cpp BUG=397258 R=tsepez@chromium.org Review URL: https://codereview.chromium.org/419063002
2014-07-24This change is for fixing the potential integer overflow from "offset + size"JUN FANG
BUG=382667 R=palmer@chromium.org Review URL: https://codereview.chromium.org/322333002
2014-07-23Refactor CFX_BasicArray.chromium/2112chromium/2111chromium/2110chromium/2109chromium/2108chromium/2107chromium/2106chromium/2105chromium/2104Chris Palmer
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
2014-07-18pdfium: Fix all -Wdelete-non-virtual-dtor violations on Mac.Nico Weber
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
2014-07-08Remove custom memory managerBo Xu
BUG= R=palmer@chromium.org Review URL: https://codereview.chromium.org/372473003
2014-05-23Convert all line endings to LF.John Abd-El-Malek
2014-05-17Initial commit.John Abd-El-Malek