[llvm-dev] question on the signature of malloc

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 15 11:32:34 PDT 2020


It's simply wrong.

On many 64-bit targets, it will appear to work anyway, depending on your luck, due to the way calling conventions works.

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Jason -Zhong Sheng- Hu via llvm-dev
Sent: Tuesday, April 14, 2020 6:49 PM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] question on the signature of malloc

Hi all,

consider the following function from Core.cpp in LLVM 9.0.0:

LLVMValueRef LLVMBuildMalloc(LLVMBuilderRef B, LLVMTypeRef Ty,
                             const char *Name) {
  Type* ITy = Type::getInt32Ty(unwrap(B)->GetInsertBlock()->getContext());
  Constant* AllocSize = ConstantExpr::getSizeOf(unwrap(Ty));
  AllocSize = ConstantExpr::getTruncOrBitCast(AllocSize, ITy);
  Instruction* Malloc = CallInst::CreateMalloc(unwrap(B)->GetInsertBlock(),
                                               ITy, unwrap(Ty), AllocSize,
                                               nullptr, nullptr, "");
  return wrap(unwrap(B)->Insert(Malloc, Twine(Name)));
}

In this code I highlighted the line which I have question on. the signature of malloc is

void *malloc(size_t size);

is this suspiciously wrong that this builder assumes size_t is 32 bit int? will LLVM backend smart enough to link the right one, which in 64 bit system is 64 bit int?

Thanks,
Jason Hu
https://hustmphrrr.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200415/882aece9/attachment.html>


More information about the llvm-dev mailing list