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

[Richard Smith via cfe-dev]

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

> 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>