pdfium.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2016-09-29	Move core/fpdfapi/fpdf_parser/include to core/fpdfapi/fpdf_parser	dsinclair
	BUG=pdfium:611 Review-Url: https://codereview.chromium.org/2383543002
2016-09-29	Move core/fpdfapi/fpdf_page/include to core/fpdfapi/fpdf_page	dsinclair
	BUG=pdfium:611 Review-Url: https://codereview.chromium.org/2379033002
2016-09-28	Use string pools in some dictionaries, names, and strings.	tsepez
	BUG=pdfium:597 Review-Url: https://codereview.chromium.org/2345063002
2016-09-20	Make CPDF_Array not do indirect object creation.	tsepez
	We remove the indirect object holder argument and check that call sites pass ownable objects, adding a reference in one place that always was passing an indirect object. Also check that the invariant isn't violated, we need to fail here in the wild and investigate -- these are existing UAFs. Review-Url: https://codereview.chromium.org/2355083002
2016-09-20	Assert that dictionary can own the objects it is given.	tsepez
	Upon indirect object holder destruction, all indirect objects are destroyed -- currently by order of increasing object number -- but ideally without ordering constraints. So currently, we can get away with a dictionary pointing directly at an indirect object with a higher number. It gets destroyed first, invoking Release() on its subordinates, which skips destroying them if they are indirect objects. But we don't want to rely on this artifact of destruction order. Should it happen to be reversed, the dictionary would invoke Release() on freed memory. Interestingly, CPDF_Array skirts the issue by replacing any indirect objects it is given with references. Not clear whether we should do the same thing for dictionaries, or remove it from arrays. The technique certainly complicates understanding ownership. The one violation found is in the unittest that broke the previous CL which tried to use unique_ptrs in indirect object holder. Review-Url: https://codereview.chromium.org/2353093002
2016-09-15	Rename dictionary set and get methods	dsinclair
	This Cl makes the Get and Set methods consistenly use {G\|S}et<Type>For. BUG=pdfium:596 Review-Url: https://codereview.chromium.org/2334323005
2016-08-25	Check for nullptrs in CPDF_Dictionary dtor.	thestig
	BUG=597440 Review-Url: https://codereview.chromium.org/2273293003
2016-08-23	Fix stack overflow in object Clone() functions	weili
	For some complex objects such as CPDF_Dictionary, CPDF_Array, CPDF_Stream, and CPDF_Reference, Clone() could be executed with infinite recursion to cause the stack overflow. Fix this by checking already cloned objects to avoid recursion. BUG=pdfium:513 Review-Url: https://codereview.chromium.org/2250533002
2016-07-15	Use CPDF_Dictionary::SetAtReference instead of CPDF_Dictionary::AddReference.	jaepark
	The definitions of CPDF_Dictionary::SetAtReference and CPDF_Dictionary::AddReference are identical, and AddReference is only used once. So remove CPDF_Dictionary::AddReference method and use CPDF_Dictionary::SetAtReference instead. Review-Url: https://codereview.chromium.org/2161453002
2016-05-23	Change CPDF_Boolean to use bool instead of FX_BOOL.	thestig
	Review-Url: https://codereview.chromium.org/1999313002
2016-04-14	Make CPDF_Dictionary methods take CFX_ByteString arguments	tsepez
	This will help avoid duplicate allocation of CFX_ByteStrings when the caller already has one. It may seem counter-intuitive that requiring the caller to pass an allocated CFX_ByteString rather than a static CFX_ByteStringC would improve the situation, but due to the idiosyncrasies of std::map, the CPDF_Dictionary methods must always do an allocation under the covers which can't be avoided. The changed callers in this CL are places where we would previously demote to CFX_ByteStringC and then allocate a a duplicate CFX_ByteString in the dictionary method. Review URL: https://codereview.chromium.org/1889863002
2016-04-11	Remove CPDF_Object::GetConstString and overrides	tsepez
	GetConstString() has sharp edges in that when applied to a CPDF_Number, it must return null whereas GetString() returns a the stringified number, because of the inability to control the lifetime of the underlying allocated string. Deleting this method showed several places where we actually wanted a String, not a StringC, so we were re-allocating a string we already had. Review URL: https://codereview.chromium.org/1879683002
2016-03-29	Rename GetElementValue() to GetDirectObject{By,At}().	tsepez
	Every time I read this code, I have to make the mental substituion that "Element value" means "de-ref indirect object", so it might as well just say so. BUG= Review URL: https://codereview.chromium.org/1841173002
2016-03-25	Remove FX_DWORD from core/ and delete definitionchromium/2695 chromium/2694 chromium/2693 chromium/2692	tsepez
	Review URL: https://codereview.chromium.org/1832173003
2016-03-15	core/include/fdpfapi cleanup Part I.	Dan Sinclair
	This Cl moves a bunch of the files from core/include/fpdfapi to their correct location outside the core/include tree. R=tsepez@chromium.org Review URL: https://codereview.chromium.org/1805603002 .
2016-03-14	Move core/src/ up to core/.	Dan Sinclair
	This CL moves the core/src/ files up to core/ and fixes up the include guards, includes and build files. R=tsepez@chromium.org Review URL: https://codereview.chromium.org/1800523005 .