Define ``_DEFAULT_SOURCE`` in ``random.c`` and ``alloc.c``. The macro
is required for ``syscall()`` and ``realpath()``. Other files like
``os.c`` already define the macro.
Signed-off-by: Christian Heimes <christian@python.org>
Fix warning ``warning: function declaration isn’t a prototype`` when
building mimalloc with ``-Wstrict-prototypes`` flag. In C argumentless
functions should be declared as ``func(void)``.
Reproducer:
```shell
$ cmake ../.. -DCMAKE_C_FLAGS="-Wstrict-prototypes"
$ make VERBOSE=1
```
Co-authored-by: Sam Gross <colesbury@gmail.com>
Co-authored-by: Neil Schemenauer <nas@arctrix.com>
Signed-off-by: Christian Heimes <christian@python.org>
The implementation of arc4random_buf differs from its documentation. It
is documented as "always successful, and no return value is reserved to
indicate an error" for the sake of FreeBSD compatibility [1]. However,
the actual implementation on macOS invokes function "ccrng_generate" [2]
without validating the error cases. It might fail silently[3], which leads
to unexpected source of entropy.
The original arc4random used the RC4 a.k.a. ARC4 algorithm, and ChaCha20
based implementation was introduced in FreeBSD 12.0. Since macOS 10.12,
it was replaced with the NIST-approved AES cipher, and it may be replaced
again in the future as cryptographic techniques advance. Therefore, we
should not assume that arc4random never fails.
On the contrary, CCRandomGenerateBytes(), part of Cryptographic Services [4],
returns cryptographically strong random bits with explicit status code.
This patch properly calls CCRandomGenerateBytes() and checks the status.
[1] https://www.freebsd.org/cgi/man.cgi?query=arc4random_buf
[2] https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60178.40.2/lib/CommonRandom.c.auto.html
[3] https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/arc4random.c.auto.html
[4] https://developer.apple.com/documentation/security
When building some code against mimalloc with C inside Visual Studio
with ClangCL, the compiler complains about __GNUC__ being undefined.
Reported by Mojca Miklavec.
Close#422
SI prefixes [the decimal prefixes] refer strictly to powers of 10. They
should not be used to indicate powers of 2. e.g., one kilobit
represents 1000 bits instead of 1024 bits. IEC 60027‐2 symbols are
formed adding a "i" to the SI symbol (e.g. G + i = Gi).
The standard way of cmake install to a destination folder is the following pattern:
```shell
cd <BUILD_DIR>
cmake <SRC_DIR>
cmake --build <BUILD_DIR>
cmake --install <BUILD_DIR> --prefix <INSTALL_DIR>
```
Right now, the `<INSTALL_DIR>` folder passed in cmake --install command is ignored,
and always installed into `C:/Program Files(x86)/...`, which is the default
`CMAKE_INSTALL_PREFIX` value passed at the `cmake <SRC_DIR>` call.
Thus, it is not possible to install the binaries into different folders
without rerun the cmake/build process.
The important thing here is, the cmake variable `CMAKE_INSTALL_PREFIX`
is supposed to be passed at `cmake --install` time with the `--prefix` argument.
In cmake file, `install` with relative path will use that prefix automaticlly.
And it is the best practice to not include CMAKE_INSTALL_PREFIX
in the `install(... DESTINATION )` argument:
```
In particular, there is no need to make paths absolute by prepending
CMAKE_INSTALL_PREFIX; this prefix is used by default if the DESTINATION is a relative path.
```
referenced from: https://cmake.org/cmake/help/latest/command/install.html
