ObjFW  History of src/exceptions/OFLinkFailedException.h of 8ed8b90cd86555ad

Instead, explicitly declare them, as OF_ASSUME_NONNULL_{BEGIN,END} does
not apply to implicit return types. This means that after this commit,
all init methods have a nonnull return type, as they should have. file: [a01a95a159] check-in: [2f4e0df8be] user: js, branch: trunk, size: 2183 [annotate] [blame] [check-ins using] [diff]

This removes several initializers that omitted the errNo. Removing those
forces to think about whether there is a meaningful errNo to set instead
of just omitting it. file: [dc4516a136] check-in: [4f36894ce7] user: js, branch: trunk, size: 2155 [annotate] [blame] [check-ins using] [diff]

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

This changes retaining behavior, meaning properties are not returned
retained and autoreleased anymore, so a property returned from a getter
now needs to be manually retained and autoreleased before calling the
setter. However, this is rarely the case and not using atomic improves
performance. file: [ecccdc69a0] check-in: [0a73af49f0] user: js, branch: trunk, size: 2712 [annotate] [blame] [check-ins using] [diff]

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

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

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

This increases the required GCC version from 4.0 to 4.6 (exception:
Apple GCC, which already supports this with >= 4.0 starting with OS X
10.5). Since even GCC 4.6 is really old by now, there is no point in
still supporting something even older and making the code ugly because
of that. While some hardware and OS support was dropped from GCC 4.6
compared to GCC 4.0, there is nothing in there that would be an
interesting target with the exception of BeOS maybe - but a port to BeOS
can also be achieved using the Haiku support. The other dropped OSes are
mostly old versions of OSes while newer ones are still being supported
(and those newer versions of those OSes still support the same
hardware). file: [1e06f0a96b] check-in: [48980f2297] user: js, branch: trunk, size: 2006 [annotate] [blame] [check-ins using] [diff]

The old behaviour where the exception would access errno directly on
creation of the exception was very fragile. The two main problems with
it were that sometimes it would pick up an errno even though none had
been set and in other cases that when the exception was created errno
had already been overridden.

This also greatly increases errno handling on Win32, especially in
conjunction with sockets. It can still be improved further, though. file: [4ee2fb6264] check-in: [62e2de30b9] user: js, branch: trunk, size: 2270 [annotate] [blame] [check-ins using] [diff]

This mostly removes the argument for the class in which the exception
occurred. As backtraces were recently added for all platforms, the
passed class does not give any extra information on where the exception
occurred anymore.

This also removes a few other arguments which were not too helpful. In
the past, the idea was to pass as many arguments as possible so that it
is easier to find the origin of the exception. However, as backtraces
are a much better way to find the origin, those are not useful anymore
and just make the exception more cumbersome to use. The rule is now to
only pass arguments that might help in recovering from the exception or
provide information that is otherwise not easily accessible. file: [89eda619ec] check-in: [3d16a30f41] user: js, branch: trunk, size: 2045 [annotate] [blame] [check-ins using] [diff]

This is safe as an "exception loop" can't happen, since if allocating
an exception fails, it throws an OFAllocFailedException which is
preallocated and can always be thrown.

So, the worst case would be that an autorelease of an exception fails,
triggering an OFOutOfMemoryException for which there is no memory,
resulting in an OFAllocFailedException to be thrown. file: [1e0f3671d5] check-in: [e1e7ffa903] user: js, branch: trunk, size: 1895 [annotate] [blame] [check-ins using] [diff]