Dipanjan Das via llvm-dev
2017-Oct-27 10:01 UTC
[llvm-dev] Why does LLVm 3.8.0 recognize fputs_unlocked as a vararg function?
Considering F represents the function fputs_unlocked() in an LLVM pass, => F->isVarArg() returns true => F->getNumParams() returns 0 => *F returns declare i32 @fputs_unlocked(...) The signature of fputs_unlocked from man page is: int fputs_unlocked(const char *s, FILE *stream); Can anybody explain why fputs_unlocked() is recognized as a vararg method while it accepts two fixed parameters? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/b8d2a3e3/attachment.html>
Tim Northover via llvm-dev
2017-Oct-27 10:22 UTC
[llvm-dev] Why does LLVm 3.8.0 recognize fputs_unlocked as a vararg function?
On 27 October 2017 at 11:01, Dipanjan Das via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Can anybody explain why fputs_unlocked() is recognized as a vararg method > while it accepts two fixed parameters?Are you sure the correct header has been included? Without that declaration the legacy C rules dictate essentially that prototype. Clang ought to give a warning about it though. Tim.
Dipanjan Das via llvm-dev
2017-Oct-27 16:41 UTC
[llvm-dev] Why does LLVm 3.8.0 recognize fputs_unlocked as a vararg function?
I tested on a sample program and it seems to work correctly. Precisely, the issue happens on base64/uniq/md5sum source code in LAVA-M ( http://moyix.blogspot.com/2016/10/the-lava-synthetic-bug-corpora.html) dataset while instrumenting by DataFlowSanitizer pass of LLVM 3.8.0. On 27 October 2017 at 03:22, Tim Northover <t.p.northover at gmail.com> wrote:> On 27 October 2017 at 11:01, Dipanjan Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Can anybody explain why fputs_unlocked() is recognized as a vararg method > > while it accepts two fixed parameters? > > Are you sure the correct header has been included? Without that > declaration the legacy C rules dictate essentially that prototype. > Clang ought to give a warning about it though. > > Tim. >-- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/16c40bcc/attachment.html>