[PATCH] D68377: [Builtins] Teach Clang about memccpy
Dávid Bolvanský via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Oct 4 12:54:21 PDT 2019
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.
================
Comment at: include/clang/Basic/Builtins.def:983
// POSIX string.h
+LIBBUILTIN(memccpy, "v*v*vC*iz", "f", "string.h", ALL_GNU_LANGUAGES)
LIBBUILTIN(stpcpy, "c*c*cC*", "f", "string.h", ALL_GNU_LANGUAGES)
----------------
aaron.ballman wrote:
> xbolva00 wrote:
> > aaron.ballman wrote:
> > > xbolva00 wrote:
> > > > aaron.ballman wrote:
> > > > > Isn't `memccpy` supported by Visual Studio? What should happen there?
> > > > ”This POSIX function is deprecated. Use the ISO C++ conformant _memccpy instead.“
> > > Thanks for verifying it's still supported (deprecated != unsupported). We do support other Microsoft builtins, so should this one be added?
> > Ok, I will add it.
> >
> > One last question, should I somehow represent that memccpy is in C 20 (if so, how) ?
> You should probably start a new section for C2x library functions and add `memccpy`, `strdup`, and `strndup` to it.
>
> Also, just to double-check: we don't encode `restrict` into builtin signatures, do we? (Should we?)
>> You should probably start a new section for C2x library functions and add memccpy, strdup, and strndup to it.
Okay, thanks - probably not needed for now (should be separate patch to handle new functions in C 2X anyway; maybe more functions to be added?)
>> Also, just to double-check: we don't encode restrict into builtin signatures, do we? (Should we?)
Maybe catch very simple overlap issues? I dont think this is worth it (we have sanitizers). LLVM annotates libc functions with noalias anyway.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68377/new/
https://reviews.llvm.org/D68377
More information about the cfe-commits
mailing list