On Fri, 9 Feb 2018 at 14:25, David Vandevoorde <daveed_at_[hidden]> wrote:

> On Feb 9, 2018, at 4:57 PM, Richard Smith <richardsmith_at_[hidden]>
> wrote:
>
> On Fri, 9 Feb 2018 at 13:08, Myria <myriachan_at_[hidden]> wrote:
>
>> Is it worth mentioning that an implementation may have other
>> mechanisms that create storage in the manner of malloc? For example,
>> it'd make sense for VirtualAlloc or mmap to create implicit objects
>> just like the standard malloc functions.
>>
>
> Sounds like a good change to me.
>
>
>
> It would be nice if we could indicate that in a portable way. The default
> is wrong for attributes, unfortunately, but otherwise something like:
>
> [[blessed_storage]] void* my_memory_map(…);
>
> would have been useful.
>

Yes, it's annoying that attributes don't work out here. I think we won't
need any annotations at all in the actual source code for most such
functions in practice, because these functions result in syscalls that are
opaque to the optimizer anyway (for all it knows, the kernel might have
created objects in the storage...). But there are likely exceptions that
have a C++ implementation that might get combined with the program source
code via link-time optimization, and we do need to avoid bad things
happening in that case.


> Incidentally, I’m not too fond of the name “bless”. Maybe
> “implicit_lifetime”?
>

Maybe I should just call it `bikeshed` until this gets to LEWG :)