Hi,
On 2018-03-25 00:07:11 +1300, Thomas Munro wrote:
> I spotted a couple of typos and some very minor coding details -- see
> please see attached.
Thanks, applying 0001 in a bit.
> From 648e303072c77e781eca2bb06f488f6be9ccac84 Mon Sep 17 00:00:00 2001
> From: Thomas Munro <thomas.munro@enterprisedb.com>
> Date: Sat, 24 Mar 2018 23:12:40 +1300
> Subject: [PATCH 2/2] Minor code cleanup for llvmjit_wrap.cpp.
>
> llvm::sys::getHostCPUName()'s result is a llvm::StringRef. Its data() member
> function doesn't guarantee a null-terminated result, so we'd better jump
> through an extra hoop to get a C string.
Hm, I checked, and it's fine, I'm not enthusiastic about this...
> It seems better to use LLVMCreateMessage() rather than strdup() to allocate
> the copy returned by LLVMGetHostCPUFeatures() and LLVMGetHostCPUName(),
> since the contract is that the caller should free it with
> LLVMDisposeMessage(). While we can see that LLVMCreateMessage() and
> LLVMDisposeMessage() are currently just wrappers for strdup() and free(),
> using them symmetrically seems like a good idea for future Windows support,
> where DLLs can be using different heap allocators (the same reason we provide
> PQfreemem in libpq).
I just kept it similar to nearby functions in the LLVM code.
> Fix brace style.
I tried to keep this as it's submitted to LLVM, I hope we can get rid of
them for newer version soon... I think I'll update them to be exactly
the same as soon as the upstream patch is applied.
Greetings,
Andres Freund
