Yes, I agree with you. Choosing "unsafe" operations is a tradeoff since Typed FFI is unavailable, I need a convenient and practical framework. I am sure, in the future, I will rewrite it without FFI.
images/flomap was a great starting point. Anyway, it is a longterm plan. On Sun, Jul 2, 2017 at 8:14 AM, Neil Van Dyke <n...@neilvandyke.org> wrote: > Any standard pixmap library that is sufficiently fast *without* using > "unsafe" language is a win. Pixmap libraries are one of the most prolific > class of unacceptably buggy code implemented C, and routinely provide > remote exploit vectors via Web browsers and copied document files, as well > as finely targeted attacks via email. > > I was hoping something like Rust would solve this problem for GNU/Linux, > of sufficiently good C programming being too difficult in practice. But > the Rust language and toolchain now have size, complexity, and security > issues of their own to address. > > Not that I expect GNU/Linux developers to start implementing a significant > portion of userspace in Racket. Though I have some idea how it might > possibly be made to happen, politically, if people were first ready to > commit skilled person-years to particular technical issues. In the > meantime, making linguistically "safe" programs with sufficiently good > performance is a good direction. (I'd prefer to mostly save "unsafe" for > things like numeric-intensive modules that really need whatever boost, and > that are tractably verifiable. If we start doing unsafe operations on > blocks of bytes, for example, without verification, we probably start > recreating many of the same mistakes we'd make in C.) > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
