- 18 Nov, 2016 1 commit
-
-
Nikias Bassen authored
-
- 13 Nov, 2016 1 commit
-
-
Nikias Bassen authored
-
- 10 Nov, 2016 4 commits
-
-
Filippo Bigarella authored
If the allocation fails, a lot of bad things can happen so we check the result and return accordingly. We also check that the multiplication used to calculate the buffer size doesn't overflow. Otherwise this could lead to an allocation of a very small buffer compared to what we need, ultimately leading to arbitrary writes later on.
-
Filippo Bigarella authored
offset_table_index is read from the file, so we have full control over it. This means we can point offset_table essentially anywhere we want, which can lead to an out-of-bounds read when it will be used later on.
-
Filippo Bigarella authored
-
Filippo Bigarella authored
-
- 09 Nov, 2016 1 commit
-
-
Filippo Bigarella authored
-
- 22 Oct, 2016 1 commit
-
-
Nikias Bassen authored
-
- 18 Sep, 2016 1 commit
-
-
Nikias Bassen authored
This removes the timeval union member from the plist_data_t structure. Since struct timeval is 2x64bit on 64bit platforms this member unnecessarily grew the union size to 16 bytes while a size of 8 bytes is sufficient. Also, on 32bit platforms struct timeval is only 2x32bit of size, limiting the range of possible time values. In addition the binary property list format also stores PLIST_DATE nodes as double.
-
- 12 May, 2016 1 commit
-
-
Nikias Bassen authored
Using a better hashing algorithm and a larger hash table the conversion is A LOT faster when processing large plists. Thanks to Xiao Deng for reporting this issue and suggesting a fix.
-
- 05 Feb, 2015 1 commit
-
-
Nikias Bassen authored
-
- 31 Jan, 2015 2 commits
-
-
Nikias Bassen authored
When parsing binary plists with BPLIST_DICT or BPLIST_ARRAY nodes that are referenced multiple times in a particular file, a buffer was allocated that was not used, and also not freed, thus causing memory leaks.
-
Nikias Bassen authored
Given a specifically ordered binary plist the function plist_from_bin() would free BPLIST_DICT or BPLIST_ARRAY raw node data that is still required for parsing of following nodes. This commit addresses this issues by moving the memory free to the end of the parsing process.
-
- 09 Oct, 2014 1 commit
-
-
Martin Szulecki authored
The parsing logic for binary dictionaries wrongly enforced the key type even on nodes that were already parsed as value nodes. This caused the resulting plist_t node tree to have key nodes instead of value nodes within dictionaries for some valid binary plists. This commit should also generally fixes parsing of binary plist files which use an efficient dictionary reference table.
-
- 03 Oct, 2014 2 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 23 Sep, 2014 1 commit
-
-
Nikias Bassen authored
-
- 25 Aug, 2014 1 commit
-
-
Aaron Burghardt authored
-
- 05 Aug, 2014 1 commit
-
-
Nikias Bassen authored
-
- 23 May, 2014 1 commit
-
-
Nikias Bassen authored
-
- 18 May, 2014 1 commit
-
-
Nikias Bassen authored
-
- 06 Feb, 2014 1 commit
-
-
Nikias Bassen authored
-
- 13 Dec, 2013 1 commit
-
-
Nikias Bassen authored
-
- 17 Oct, 2013 1 commit
-
-
shane authored
Handle UTF-16 surrogate pair conversion to/from UTF-8
-
- 30 May, 2013 1 commit
-
-
Nikias Bassen authored
-
- 16 Sep, 2012 1 commit
-
-
Nikias Bassen authored
-
- 11 Feb, 2012 1 commit
-
-
Nikias Bassen authored
-
- 11 Jan, 2012 1 commit
-
-
Nikias Bassen authored
-
- 28 May, 2011 1 commit
-
-
Nikias Bassen authored
-
- 27 May, 2011 1 commit
-
-
Nikias Bassen authored
-
- 16 Mar, 2011 1 commit
-
-
Christophe Fergeau authored
-
- 29 Jul, 2010 1 commit
-
-
Jonathan Beck authored
-
- 18 Apr, 2010 1 commit
-
-
Julien BLACHE authored
- endianness issues: on big endian machines, writing out only part of an integer was broken (get_needed_bytes(x) < sizeof(x)) -> shift integer before memcpy() on big endian machines - alignment issues: unaligned reads when loading binary plist. Leads to slow runtime performance (kernel trapping and fixing things up), SIGBUS (kernel not helping us out) -> introduce get_unaligned() and have the compiler generate the code needed for the unaligned access (note that there remains unaligned accesses that I haven't been able to track down - I've seen 2 of them with test #2) - type-punning issues: breaking strict aliasing rules can lead to unexpected results as the compiler takes full advantage of the aliasing while optimizing -> introduce the plist_uint_ptr union instead of casting pointers Tested on amd64, alpha and hppa.
-
- 24 Mar, 2010 1 commit
-
-
Alexander Sack authored
* on armel system floating poing data can have different endianess than rest of types; hence we fix arm endianess for defined(__VFP_FP__) to be big/native; this also applies for data parsing/writing * date parsing didnt flip the endianess back for little endian systems when reading the values causing test failures; we fix this by ensuring float endianess is applied when parsing
-
- 21 Jan, 2010 1 commit
-
-
Jonathan Beck authored
-
- 28 Oct, 2009 2 commits
-
-
Jonathan Beck authored
-
Jonathan Beck authored
-
- 06 Sep, 2009 1 commit
-
-
Jonathan Beck authored
-
- 08 Jul, 2009 1 commit
-
-
Jonathan Beck authored
-
- 28 Apr, 2009 1 commit
-
-
Jonathan Beck authored
Merge ascii and unicode handling in PLIST_STRING using UTF-8. Remove unicode related declaration in API (breaks API&ABI)
-