ObjFW  History of src/instance.h of f663d40cbd42bf95c37b1415cf717ae147690f1eb69fa5f7d08f06e8d4da7ff1

Casts are now written like types in variable declarations. file: [0671acd0b4] check-in: [4af49a13c3] user: js, branch: trunk, size: 824 [annotate] [blame] [check-ins using] [diff]

Forgot to add 2017, even though I already did quite some changes in
2017. file: [69b1191150] check-in: [44f45c2e35] user: js, branch: trunk, size: 824 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [876e496d27] check-in: [cec0f072f8] user: js, branch: 0.8, size: 822 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [986f7820a8] check-in: [2a27cf3000] user: js, branch: trunk, size: 818 [annotate] [blame] [check-ins using] [diff]

Now that Clang switched to use _Nullable and _Nonnull instead of
__nullable / __nonnull, there is no longer a conflict with glibc, which
means we can just define _Nullable / _Nonnull to nothing if they are not
understood by the compiler (which did not work with __nullable /
__nonnull due to this conflict).

This also defines _Null_unspecified to nothing if unavailable. file: [4dd0773bd7] check-in: [d526d938d7] user: js, branch: trunk, size: 814 [annotate] [blame] [check-ins using] [diff]

Using __nonnull directly doesn't work on systems using glibc, as glibc
defines __nonnull as a parameterized define. While this does not fix the
problem of Clang introducing __nonnull even though it conflicts with
glibc, this at least means it's possible again to compile things with
versions of Clang that don't support __nonnull on systems with glibc. file: [8f8be6243f] check-in: [b7097a67b6] user: js, branch: trunk, size: 818 [annotate] [blame] [check-ins using] [diff]

OS X < 10.6 did not have it, so it is built regardless of the selected
runtime now if objc_constructInstance() hasn't been found. file: [bb544f5a22] check-in: [16ba7ec477] user: js, branch: trunk, size: 708 [annotate] [blame] [check-ins using]