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.mu...@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
