cast(anydata) + RLS = unhandled overflow

I encountered an issue that I finally was able to reproduce using ANYDATA within RLS/VPD. I initially thought to post the testcase here, but I believe it exceeds the size of oracle-l messages, so I am linking a write-up: http://orajourn.blogspot.com/2010/02/vpd-bad-anydata-practices-can-really.html

<http://orajourn.blogspot.com/2010/02/vpd-bad-anydata-practices-can-really.html>For those that know how to dig into internals really well, I have a question about the "behind the scenes" stuff, the nitty-gritty of "how Oracle works". What exactly is happening? What about using CAST to force ANYDATA to a smaller format window than the value itself within the context of a RLS policy forces the kernel to modify the inserted date such that the Century bit(s) of the date are altered? It is my suspicion that the kernel maps the truncated ANYDATA in the predicate to the select list, and overflows the bits from the rest of the ANYDATA value to the next column - in my case, the next column just happened to be a date, and since the Century bit is the highest order bit, it is altered "in route" and becomes a few millenia too old. But how and why? How do I prove this?

I look forward to learning from you.
Hat tip to Maxim Demenko for his earlier lesson about how to alter dates.

PS - For those that have access to Metalink SRs:

3-1431865081 DATE datatype showing out-of-range values

3-1454460075 ORA-07445: exception encountered: core dump [_memcpy()+116]

3-1453539464 Questions on FGAC and VPD

3-1453029347 Viewing transactions in logminer

-- 
Charles Schultz

--
http://www.freelists.org/webpage/oracle-l