summaryrefslogtreecommitdiff
path: root/fpdfsdk/include/fsdk_mgr.h
AgeCommit message (Collapse)Author
2015-06-10Remove typdefs for pointer types in fx_system.h.Tom Sepez
This involves fixing some multiple variable per line declarations, as the textually-substituted "*" applies only to the first one. This involves moving some consts around following the substitution. This involves replacing some typedefs used as constructors with better code. R=thestig@chromium.org Review URL: https://codereview.chromium.org/1171733003
2015-06-08Remove more cruft from fx_system.hTom Sepez
- 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
2015-05-28Fix ALL the include guards.Tom Sepez
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
2015-05-11Create top-level public/ header directory.Tom Sepez
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
2015-03-02Kill off JS_ErrorString type.Tom Sepez
This provides no benefit, and reduces transparency. Along the way: Kill off some unused/commented-out code. Return void where a bool return doesn't make sense. Remove a pointless template type. Remove now unused constants and types. R=thestig@chromium.org Review URL: https://codereview.chromium.org/971033002
2015-02-05Merge to master: Kill off some dodgy JS callbacksTom Sepez
Note that this work was done opposite the usual branch order, because I didn't want to kill things in master that turned out to be in use in XFA. Original Review URL: https://codereview.chromium.org/883393007 TBR=jam@chromium.org Review URL: https://codereview.chromium.org/903893002
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