From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Heartbleed Date: Thu, 17 Apr 2014 21:01:39 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> <%J32v.70539$kp1.45343@fx14.iad> <87tx9so50m.fsf@adaheads.sparre-andersen.dk> Injection-Date: Thu, 17 Apr 2014 21:01:39 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="15817"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ttGHixCQd/6DdR5AbrJZqZt3CKVOBgxs=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:m/7eKdLgmgnfOwfdMbsbg9UCI50= X-Original-Bytes: 3860 Xref: number.nntp.dca.giganews.com comp.lang.ada:185791 Date: 2014-04-17T21:01:39+00:00 List-Id: On 2014-04-17, Jacob Sparre Andersen wrote: > Simon Clubley wrote: > >> The goal here is to replace C when writing libraries which are used on >> a vast range of platforms (like OpenSSL). That simply isn't going to >> happen unless the compiler runs on the same range of platforms C >> compilers currently run on and unless the code generator in the >> compiler generates code for the same range of targets the C compilers >> currently do. > > Would something as simple as having the choice of compiling to C be > enough? Then you could always generate a C library/application for a > target without direct support. > That takes care of the code generation/target platform selection part of the compiler (if potentially not handling debugging issues [*]) but it doesn't tackle the issue of the range of platforms the compiler itself runs on. If the compiler's implementation language isn't available on the same range of host/development platforms as C is then you still have the same issues as above and people are not going to use your new compiler. I've thought about this a bit more over the last day or so and issues like this are why I keep (sadly) coming back to C as the implementation language for the core compiler itself although the libraries and the run time library could be written in the language itself. If you want to replace C, you can either (1) take the idealistic approach, which so far has shown no real signs of succeeding even though we have had Ada available for truly free use (in the form of the FSF compiler) for a long time now, or (2) you can take a more pragmatic approach. (And if it makes you feel better, the Fortran compiler in gcc is not written in Fortran... :-)) [*] If you generate C code, then you also have the issue of making sure any debugger uses the original source code and not the generated C code. I don't know if it's possible to insert the required debugging data into C code in the same way as you can with assembly code intended for gas. > I will not claim that I expect it to be easy to target any random C > compiler, but it might be doable. > > I can't tell if it would help replacing C or cement C's status as the > defacto standard programming language. > It wouldn't be a programming language any more when used as the output of a code generator. It would simply be the generated representation of the program in the same way as the gas (GNU assembler) output from gcc is the generated representation of the program compiled with gcc. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world