Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Branch: master
Commits on Jul 12, 2012
  1. Add a `#ifdef` to silence a `clang` static analyzer false positive wa…

    authored
    …rning.
    
    The current (at the time of this writing) version of the `clang` static analyzer is complaing that the `objects` pointer is `NULL`.  This is a false positive warning from the analyzer.
Commits on Jun 24, 2012
  1. Silences some warnings that newer versions of the compiler(s) complai…

    authored
    …n about.
    
    1. Some of the string format argument specifiers used `%lu` to display `NSUInteger` values.
    
    `%lu` specifies a type of `unsigned long`, and `NSUInteger` maps to either `unsigned int` or `unsigned long`, depending on whether or not you're targeting a 32-bit or 64-bit ABI, respectively.
    
    On a 32-bit architecture (at least for the architectures / compilers that JSONKit will be used on), `unsigned long` and `unsigned int` just so happen to use the same primitive type- a 4 byte 32-bit value.
    
    On a 64-bit architecture (again, for the architectures / compilers that JSONKit will be used on), `unsigned int` stays the same at 4 bytes, however `unsigned long` grows to 64-bits / 8 bytes.
    
    The long and the short of it is this that using `%lu` allows you to easily support 32-bit and 64-bits with out a lot of effort.
    
    However, technically, the C standard says that `int` and `long` are strictly different ranks, and it's generally considered poor form to take advantage of platform specific details in this case.
    
    The proper fix is to add explicit type casts to `unsigned long`.  This makes the implied behavior explicit, and eliminates the warnings from newer versions of the compiler.
    
    FYI, `gcc` did this for a long time and seems to be something that is either new or enabled by default in `clang` / `Xcode`.
    
    Other good warning flags you should consider enabling by default (from Xcode 4.3):
    
    Implicit Conversion to 32 Bit Type
    Suspicious Implicit Conversions
    Hidden Local Variables
    
    2. Newer compiler warns about deprecated `id` `isa` usage.
    
    I found jwz's commentary about breaking API's pretty funny: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
Commits on Mar 22, 2012
  1. Minor changes to hashing and cache aging algorithms.

    authored
    Hashing was changed slightly to exploit the fact that a significant amount of real world JSON strings / keys will have a high percentage of ASCII characters.
    
    Cache aging was modified to use an AIMD (additive increase, multiplicative decrease) policy.  When an item is found in the cache, its age is incremented by one using saturating arithmetic.  Ages are "quasi-randomly" aged using unsigned right shifts, or in other words its age is divided in half. Since ages decrease far more quickly than they increase, the cache can quickly adapt and converge on the "hot set".
Commits on Dec 18, 2011
Commits on Nov 17, 2011
  1. Merge pull request #58 from samsoffes/master

    authored
    Surpress "multiple methods named" error
  2. @soffes
  3. @soffes

    Surpress "multiple methods named" error

    soffes authored
    I realize that `collection` won't always be an NSArray, but the cast will let the compiler know to expect a NSUInteger return type instead of `size_t` which is also a return type a method named `count` inside of JSONKit.
Commits on Sep 23, 2011
  1. Fixes issues #9, #15, #40, aka "crashes on 64-bit Lion / 10.7 ABI".

    authored
    This commit implements a work around for a bug in 10.7 that was caused by
    a 10.7 64-bit ABI breaking change.
    
    Technically, this is not a bug in JSONKit, but with Mac OS X.
    
    When making changes to the ABI, it is (at least de facto) required to bump
    the "major version" of a shared library so that code designed around and
    built against the "guarantees" provided by previous versions ABI / API
    are not violated.
    
    Not only was this not done in 10.7, the ABI breaking change isn't even
    officially documented (to the best of my knowledge).  It's certainly not
    mentioned in the 10.7 release notes.
  2. Merge pull request #46 from jparise/cache-collisions

    authored
    Use memcmp() instead of strncmp() to compare cache buckets.
Commits on Sep 22, 2011
  1. Merge pull request #50 from atnan/fixclang2errors

    authored
    Fix compilation errors under Clang 3.0
  2. @atnan
Commits on Aug 31, 2011
  1. @jparise

    Use memcmp() instead of strncmp() to compare cache buckets.

    jparise authored
    In the rare case when a hash collision occurs between two values, the
    object cache's bucket-probing code needs to go as far as comparing the
    bytes content of the candidate bucket with the bytes content of the
    current token.
    
    For numeric values, 'bytes' refers to the raw bytes of the number.
    These byte representations may contain leading '\0' values.  strncmp()
    is only designed for comparing strings, so characters appearing after
    a '\0' are not compared.
    
    Therefore, if a hash collision occurs between two numeric values that
    only differ in their lower bytes, they will be assigned to the same
    bucket, and the cache will return the first token's object for the
    second token's value.
    
    memcmp() is binary-safe and considers all of the numbers' bytes,
    avoiding this problem.
    
    This is a rare case indeed, but here is an example that reproduces the
    problem:
    
        JSON Input:             [ 1734.75, 417.75 ]
        Identical Types:        double (8 bytes)
        Identical DJB Hashes:   2510392872
    
        JSONKit (strncmp):      [ 1734.75, 1734.75 ]    (boo!)
        JSONKit (memcmp):       [ 1734.75, 417.75 ]     (yay!)
Commits on Jun 16, 2011
  1. Added note about Automatic Reference Counting (ARC) to README.md and …

    authored
    …some preprocessor-foo to JSONKit.m to check if JSONKit is being compiled with ARC / `-fobjc-arc` and #error if it is.
Commits on Jun 5, 2011
  1. Minor tweak.

    authored
  2. Added "JKSerializeOptionEscapeForwardSlashes". Changed a number of <t…

    authored
    …able> constructions to the easier Markdown extra tables to see if the new github markdown processor accepts them. Also changed some <pre> items to ```objective-c / ``` fenced code style.
Commits on Jun 3, 2011
Commits on May 22, 2011
  1. Fix typo.

    authored
Commits on May 21, 2011
  1. Moved the +load logic from JSONDecoder in to jk_collectionClassLoadTi…

    authored
    …meInitialization(). Missed the JSONDecoder +load stuff on the last commit. Related to issue #23.
  2. Workarounds for issue #19 (the clang stuff) and issue #23. For issue #23

    authored
    , the code in the collection classes `+load` was removed and placed in a function with the `__attribute__ ((constructor))` attribute.  This is to work around an apparent bug when building JSONKit as a static library for iOS targets.  @ohhorob also opened a bug with apple- # 9461567.
Commits on May 5, 2011
  1. Merge pull request #22 from jordanbreeding/master

    authored
    Pull Xcode 4.1 update.
Commits on May 4, 2011
  1. Pacify Xcode 4.1.

    Jordan Breeding authored
Commits on May 2, 2011
Commits on Apr 25, 2011
Commits on Apr 22, 2011
  1. Fixes a bug when removing items from a JKDictionary. Since JKDictiona…

    authored
    …ry is implemented using a hash table that uses linear probing, the removal function needs to "re-add" items that follow the removed item so that linear probe hash collisions are not "lost". Closes #17
Commits on Mar 31, 2011
  1. When commiting the fix for hash % dictionary->capacity, some local, i…

    authored
    …n progress edits made it in to the commit. This change backs them out.
Commits on Mar 28, 2011
  1. Fixes a bug when trying to retrieve a key from a dictionary that cont…

    authored
    …ains no items (div by zero: (keyHash % dictionary->capacity))
  2. Modified the JSONKit so that it is dual licensed under either the BSD…

    authored
    … or Apache v2.0 license. This was motivated by the discussion at facebookarchive/three20#465
Commits on Mar 25, 2011
  1. Try to clean up githubs markdown parsing of *s in <pre> blocks... mis…

    authored
    …sed a few from the last round
Something went wrong with that request. Please try again.