ObjFW  History of src/windows_1252.m of 948a5c25ce6950a5

This used to be U+FFFD, but if a character is not assigned in an
encoding, U+FFFF is a better match. file: [4e7a49cc4a] check-in: [a9f85ba3b1] user: js, branch: trunk, size: 3672 [annotate] [blame] [check-ins using] [diff]

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

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

This means that OFObject.h imports macros.h now, making it unnecessary
to manually import macros.h in almost every file. And while at it, also
import autorelease.h in OFObject.h, so that this doesn't need to be
manually imported in almost every file as well. file: [fbc12484d1] check-in: [13ee56edf3] user: js, branch: trunk, size: 3628 [annotate] [blame] [check-ins using] [diff]

For ObjC++, these are defined to char{16,32}_t if C++11 is used. This
means passing e.g. a C++11 UTF-16 string to -[initWithUTF16String:]
works without a warning.

For C11, this is not necessary, as char{16,32}_t are just typedef'd to
uint_least{16,32}_t in <uchar.h> and thus compatible to the definition
of of_char{16,32}_t. The reason for not defining of_char{16,32}_t to
char{16,32}_t when using C11 is that <uchar.h> might be missing and that
char{16,32}_t are not required to be UTF-{16,32}, whereas in C++, they
are required to be UTF-{16,32}. file: [03d37613d5] check-in: [545b6f740e] user: js, branch: trunk, size: 2706 [annotate] [blame] [check-ins using] [diff]