kees wrote:

> You would only get a trap when you get a narrowing conversion, maybe that 
> should only be the case for _implicit_ conversions? e.g 
> `(int)some_obt_qualified_64bit_type` - I'm not sure I like that as to me it 
> feels like the idiomatic casting behaviour would silently truncate, 
> presumably unexpectedly, e.g the default developer response to an implicit 
> narrowing warning is just to add `(dest_type)expr` which would silently drop 
> high bits even though that would seem unexpected?

Right this gets to my concern about casts: I don't want a way to return to 
ambiguous values.

> It seems not unreasonable to maybe have something like `__obt_ignore` 
> qualifier in casts to make it easier to perform a narrowing cast that drops 
> instrumentation/overflow checks as a usability improvement that makes it 
> explicit that you do not care about overflow.

I want to have overflow behavior be explicit, so I think if we wanted to 
"strip" an `__ob_trap`, it should get an `__ob_wrap` cast: `(dest_type 
__ob_wrap)expr` ?

> @kees @JustinStitt Are you folk going to be at the US devmeeting? Maybe it 
> will be easier to go over in person? If not it might be easier to set up a 
> telcon or something?

Yeah, @JustinStitt will be there for sure; I can probably fly down or we can do 
a video chat. Email me at [email protected] and let's take this offline to 
coordinate?



https://github.com/llvm/llvm-project/pull/148914
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to