> On Feb 9, 2018, at 5:46 PM, Richard Smith <richardsmith_at_[hidden]> wrote:
>
> On Fri, 9 Feb 2018 at 14:25, David Vandevoorde <daveed_at_[hidden] <mailto:daveed_at_[hidden]>> wrote:
>> On Feb 9, 2018, at 4:57 PM, Richard Smith <richardsmith_at_[hidden] <mailto:richardsmith_at_[hidden]>> wrote:
>>
>> On Fri, 9 Feb 2018 at 13:08, Myria <myriachan_at_[hidden] <mailto: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.

Although in those cases the C++ implementation can have a barrier “bless” call on the inside, right?


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

Hopefully nobody will bless bikeshed :-P

 Daveed