Reading binary data

[Ty Young]

On 11/6/19 5:10 AM, Maurizio Cimadamore wrote:
> It is possible to create a memory address from a long:
>
> http://hg.openjdk.java.net/panama/dev/file/0798bb838349/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/unsafe/ForeignUnsafe.java#l75 
>
>
> This is, currently (and for good reasons) an unsafe operation, so it 
> is defined in a non-exported package which can be --add-exports(ed) if 
> the user really need to do something like that. We also have ideas on 
> how to allow operations such as these in a _safe_ way - that is, we 
> could allow creation of 'random' addressed from long (including null), 
> provided that we do not allow to safely dereference them. While this 
> is not a 100% solution it would support NULL cleanly, as well as all 
> cases where native API deal in opaque pointers.
>
> Here there's a bigger, and very interesting theme, of how should an 
> API containing both _safe_ and _unsafe_ parts should be defined in a 
> way that (i) allow programmers to do what they have to do w/o being 
> too punitive and (ii) prevents unsafe portions of the API to be 
> repackaged and re-exported to innocuous clients operating in _safe_ 
> mode. This is an hard trade-off to make, and it also doesn't help 
> that, so far, JNI has always been treated as a _safe_ player.


Speaking purely from an API design perspective, having the "safe"(high 
level) API be an extension of the "unsafe"(low level) API and hiding the 
lower level functionality via the protected visibility modifier, as was 
suggested by Samuel, and/or packaging separation sounds like the only 
real solution. Safety as an extension, if you will.


Regarding the topic of safety, it feels like important context is being 
forgotten... or maybe I'm missing something. C/C++ is primarily used for 
sensitive, low level, and hardware level programming. Any bad or 
incorrect API usage(integer overflows, for example) could result in the 
entire system -including the JVM- to explode and crash. The "safe" 
Pointer API, even with all of its safety, isn't going to prevent system 
crashes from C/C++ code. Heck, even within Java itself without Panama, 
it's possible to cause system chaos because *all roads eventually lead 
to Rome*. Anything that affects the system can affect the JVM and code 
executed in the JVM can negatively affect the system.


Which is why I was confused by both the presentation and now(regarding 
your newest email) in regards to Panama preventing crashing the VM 
directly or by extension. How is such a thing even conceivably possible 
anymore than preventing an ordinary bug from within pure Java code and 
crashing the system that way? Ignoring the context of Panama, literally 
any buggy code from any library at any point could cause huge failure.


Not saying "safety" doesn't matter, from a high level use case it 
absolutely does and is important, just that hiding API functionality 
that people want/need for this specific reason doesn't make a whole lot 
of sense. Panama can't conceivable be a one API army that somehow either 
fixes everyone's buggy code, prevents them from writing it to begin 
with, and/or smooths over buggy code. Nothing really can.


>
> I don't think the Pointer API has anything to create a Pointer from a 
> long (unless you refer to the trick of writing a long in memory, and 
> then reading it back as a Pointer).
>
> Maurizio
>