On Fri, Feb 9, 2018 at 5:50 PM, David Vandevoorde <daveed_at_[hidden]> wrote:

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


Didn't LEWG already call it byte_cast? I mean bit_cast?
How is this different?
Or does bit_cast need to call bless/bikeshed?


> Daveed
>
>
>
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
>

-- 
Be seeing you,
Tony