Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
On debian-mips, neither __LITTLE_ENDIAN__ nor __BIG_ENDIAN__ are defined
anywhere, so PLIST_BYTE_ORDER defaults to PLIST_LITTLE_ENDIAN when it should
really be PLIST_BIG_ENDIAN on this architecture.
This fixes issue #13.
|
|
On my machine, parallel builds fail with:
make[2]: Entering directory `/home/teuf/hack/libplist/src'
CCLD libplist.la
make[2]: *** No rule to make target `../src/libplist.la', needed by
`libplist++.la'. Stop.
If $(top_builddir)/src/libplist.la does not exist yet when trying to
link libplist++.la, automake/make will not realize the
$(top_builddir)/src/libplist.la dependency is the same as the
libplist.la target, and will thus be unable to generate
$(top_builddir)/src/libplist.la.
Using the libplist.la instead fixes this issue.
I've checked that srcdir!=builddir and make distcheck still pass after
this change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
strtok_r is not available on win32 and the designated strtok_s
function is reported to not work on windows xp. Hence we use an
easier an non-destructive implementation with strspn and strcspn
to strip out the whitespace.
|
|
this is a temporary fix, we'll replace strtok_r with a custom implementation soon.
|
|
iterator of NULL
|
|
Handle UTF-16 surrogate pair conversion to/from UTF-8
|
|
|
|
endianness detection
|
|
|
|
|
|
|
|
Thanks to free2000fly for pointing this out. The issue was that
XML plists with comments converted to binary plists would result
in invalid binary nodes, thus converting back these binary plists
resulted in a crash.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows dylib to correctly find the library and fixes linking on OSX.
|
|
While iterating over all the keys stored in the source Dictionary
to copy them to create the copied Dictonary, the name of the key
being copied was only set to a non-NULL value for the first key
we copy. This was then leading to an assertion when trying to
create a std::string from a NULL pointer. Simple test-case:
int main()
{
PList::Dictionary a;
PList::String b("Hello");
PList::String c("Hi!");
PList::Dictionary d;
a.Insert("Key", &b);
a.Insert("Another Key", &c);
std::cout << a.ToXml() << std::endl;
d.Insert("dictionary", &a); //CRAAAAAAAAASH!
std::cout << d.ToXml() << std::endl;
return 0;
}
/* Output:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Key</key>
<string>Hello</string>
<key>Another Key</key>
<string>Hi!</string>
</dict>
</plist>
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
*/
Signed-off-by: Martin Szulecki <opensuse@sukimashita.com>
|
|
Apple's activation server refuses XML tickets when this patch isn't applied.
|
|
|
|
- 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.
|