[cfe-dev] C++ Annex K safe C11 functions

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Wed Jan 9 12:30:59 PST 2019

On Sat, 5 Jan 2019 at 23:35, Jonny Grant via cfe-dev <cfe-dev at lists.llvm.org>

> On 04/01/2019 21:50, JF Bastien wrote:
> >> On Jan 4, 2019, at 1:47 PM, Jonny Grant <jg at jguk.org
> >> <mailto:jg at jguk.org>> wrote:
> >>
> >> Hi! Sounds great
> >> How about setting uninitialised variables to 0xdeadbeef or 0xabbaabba
> >> so its easily identifiable when they crop up in use?
> >> We used to clear buffers to 0x11111111 and stack to 0x22222222 I recall
> >
> > This isn’t relevant to the Annex K discussion, let’s keep this thread
> > focused. We discussed initialization values in the original thread as
> > well as the code review, it’s worth reading through that to see why I
> > chose the values I did (mainly so pointers are invalid, and they’re
> > repeated byte-values so the code generation is better).
> OK.
> BTW, I don't think Clang has its own libc does it? Could the other Annex
> K be added in a libc.

Yes, a libc implementation can certainly implement Annex K (or at least the
non-freestanding parts of it) itself. It would also be feasible for a
third-party library to provide an implementation of Annex K, and to
interject wrapper headers between user code and the underlying libc
providing the extra symbols.

> Or at a push, in Clang's libc++ (I know it is meant to be C11 standard,
> not C++, but C++ usually includes C functions anyway)

While C++ includes most of the C standard library, it excludes these parts;
even if libc++ chose to provide an implementation of the functions
inherited from C, it should still not include these ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190109/c36d3741/attachment.html>

More information about the cfe-dev mailing list