summaryrefslogtreecommitdiff
path: root/fpdfsdk/include/fsdk_mgr.h
AgeCommit message (Collapse)Author
2015-06-09Merge to XFA: Remove more cruft from fx_system.hTom Sepez
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
2015-06-02Replace XFA_HWIDGET with IXFA_Widget*Tom Sepez
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
2015-05-28Merge to XFA: Fix ALL the include guards.Tom Sepez
Original Review URL: https://codereview.chromium.org/1160443004 TBR=thestig@chromium.org Review URL: https://codereview.chromium.org/1162013003
2015-05-11Merge to XFA: Create top-level public/ header directory.Tom Sepez
Original Review URL: https://codereview.chromium.org/1135913002 BUG=pdfium:154 R=thestig@chromium.org Review URL: https://codereview.chromium.org/1136703003
2015-03-02Merge to XFA: Kill off JS_ErrorString type.Tom Sepez
Orignal Review URL: https://codereview.chromium.org/971033002 TBR=thestig@chromium.org Review URL: https://codereview.chromium.org/969203002
2015-02-05Kill off some dodgy JS callbacksTom Sepez
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
2015-01-08XFA: merge patch from CL 792953005, fix most warningsBruce Dawson
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
2014-11-03Lock page in LoadFXAnnot to prevent unintended page closingunknown
2014-11-03Merge XFA to PDFium master at 4dc95e7 on 10/28/2014Bo Xu
2014-09-24Lock page in LoadFXAnnot to prevent unintended page closingBo Xu
BUG=410326 R=tsepez@chromium.org Review URL: https://codereview.chromium.org/594403003
2014-07-30Speculative fix for uninitialized value in CFX_ByteString().Tom Sepez
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
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-06-24Fix and integer overflow issue in SDK's QuickSortBo Xu
BUG=382639 R=mdempsky@chromium.org Review URL: https://codereview.chromium.org/354673002
2014-05-23Convert all line endings to LF.John Abd-El-Malek
2014-05-17Initial commit.John Abd-El-Malek