I want a language that is as safe as possible and can be self hosting, hence you can write the compiler, runtime and operating system in it.
Just because you include unsafe conversion does not make all programs unsafe. You can use unsafe conversion safely. For example the compiler can write a table into binaries allowing lookup if methods and fields and cryptographically sign it. When you dynamically load the shared object you check the method type in the table with the static type you are expecting. This is done in a library you can include with your program if you want to do dynamic loading. As for fragile interfaces, you just need to confirm you are loading the correct version of the library, again a cryptographic hash or similar can be used for this. To assume there are no bugs in a program written in a unsafe language, and then to claim the language written in this is safe seems strange. It just means you will never see the backdoors, remember the concept of the backdoored compiler that inserts a backdoor into every program it compiles. A false sense of security is worse than a realistic appraisal. Much better to make the bsckdoor (unsafe conversion) visible, as it has to be there in any case. Keean. On 15 Jul 2015 6:25 am, "Matt Oliveri" <[email protected]> wrote: > On Wed, Jul 15, 2015 at 12:24 AM, Keean Schupke <[email protected]> wrote: > > You don't want to have a large runtime for a systems language. For > example > > when writing an operating system kernel, you don't want invisible code > added > > to the kernel that may be insecure. In general, if I write a program that > > does 1 + 2, I expect the binary to do exactly that, without needing to > load > > a large runtime to do that. > > I agree with the stuff above, but I don't see how it argues against > what I said. The fact is that if you want non-fragile interfaces, you > need the language to somehow support non-fragile interfaces, even if > that means you need more runtime support. > > You are only pointing out that the requirements of a systems > programming language and the requirements of a modular application > programming language are somewhat at odds. > > (Also, I don't see why runtime support for non-fragile interfaces > would have anything to do with the implementation of (1 + 2).) > > > Further I would like to write any dynamic > > loading code in my language. > > That's pretty hard, I think, if you want any sort of safety property > for your language. > > > If there is no way to do the unsafe pointer conversion in the language > then > > you cannot write the runtime in your language, and will have to write it > in > > assembly, or 'C'. This potentially makes all programs in the language > > unsafe, rather than just those explicitly using the unsafe address > > conversion primitive. > > No, not if I'm understanding you. Whether the language directly > supports unsafe pointer conversion, or supports calling native code, > it's an unsafe escape hatch. Any program using an unsafe escape hatch > may be unsafe. Programs that stick to the safe part of the language > are safe, assuming the language implementation is correct. > > The only real choice is whether non-fragile interfaces are supported > by the safe part of the language. It seems like a bad idea to allow > fragile interfaces in a safe language, because then linking a wrong > version makes your program not so safe after all. (I am assuming > breaking fragile interfaces is unsafe. This isn't necessarily true of > all languages, but seems true for the languages we're thinking of.) > > I'm starting to think that you're not aiming for a safe language, and > this is causing a miscommunication. If the language is not meant to be > safe, then I can see that your approach might be better. > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
