Slashdot Mirror
Microsoft Previews Compiler-as-a-Service Software
angry tapir writes "Microsoft will release a Community Technology Preview of a new type of compiler its researchers have been building — code-named Project Roslyn — a company executive announced Thursday. Roslyn is a compiler for C# and Visual Basic with a set of APIs that developers can use to fine-tune their code. It resembles a model developed by the Mono Project, in which the information the compiler generates about a program can be reused as a library."
Didn't NetCraft confirm it?
I'm not a lawyer, but I play one on the Internet. Blog
I would actually bet they just took mono and dotNETized it a little.
I agree 100%. I'm a huge distcc fanboi, but outsourcing compiling of code scares the shit out of me. I'd expect to see a security vulnerability where faulty code was somehow delivered to you. It's a backdoor that you run yourself, as you expect the compiler to return, you know, a compiled version of what you gave it. Nasty things in 3... 2... 1...
I don't think you even really read the summary... it essentially comes down to offering more compile abilities into an application. This can work for extensible plugins, and scripting. It is not the compiler offered via a SaaS (Software as a Service) model.
Michael J. Ryan - tracker1.info
http://cm.bell-labs.com/who/ken/trust.html
It is left as a exercise to the reader to see the point I'm trying to make.
It will play into the Azure platform if it's a pure service. You can run an application on Azure with a SQL backend, and have this new compiler service build it for you.
Although from the article, I didn't even get a sense of that being the purpose. From what i was seeing, it's just a service you can run while developing that will give you more insight into the compiler's workings. You access it via VS2010 like you normally do.
I'm curious how this would play into TFS as well, if you could get more information to be pumped out from MSBuild to some sort of report.
It's going to have a GUI?
it means nothing like this (and i hate the name of it because of it). it means you have much more ways to use the compiler. it still is on your desktop, still 100% in your control. but it's not a blackbox anymore, it's now something you can plug in own stuff, extend, reuse, etc.
I don't think you even really read the summary...
I don't think you read the (already classic?) Ken Thompson's Reflections on Trusting Trust
"You can't trust code that you did not totally create yourself." - if your binary compiler injects a backdoor in the object code, then even recompiling the compiler from source may not get you out of the woods.
Otherwise, let point to you the (in my opinion) relevant phrases in TFA:
Today's commercial compilers are black boxes, Hejlsberg said.
While Hejlsberg is probably right, fortunately in this world there are such things as non-blackbox-compilers.
Questions raise, answers kill. Raise questions to stay alive.
It's actually more about exposing the internal compiler metadata to the outside world. MS' very own LLVM essentially.
It's not about software-as-a-service compilers, it's about exposing the internal data structures and information a compiler produces to the programmer. This lets you go a level beyond introspection and into some interesting possibilities.
I do not fail; I succeed at finding out what does not work.
There is something about this concept that I find very threatening. Service Orientated Architecture is no doubt a good thing and Software as a Service can save costs. However with something as simple as a compiler being outsourced to the platform vendor, this returns control over software creation that can be produced squarely with the vendor.
Imagine a vendor that could suppress the compilation of software that it deems unfavourable. A company would never refuse to provide a compiling contract to a business that makes products that compete with the vendor, would they? They would not create a terms of service that deems what software is appropriate to be compiled?
Have you ever heard of Apple's App Store? It's this crazy store which is the only place you can get applications for your phone or tablet, and Apple controls every piece of software published on it. Apple also imposes arbitrary bans on applications whenever Apple sees fit. Apple is also trying to push this model to their laptops and personal computers. Furthermore if you want to make your own applications run on your iDevice you have to pay apple $100, or violate the TOS to unlock your phone. That's right, imagine that, you outright own a device, but you don't have the right to administer it.
Thanks but no thanks, I think I'll be sticking with offline compilers
Will nobody ever think of the NSA ? You must be a terrorist.
No, you're not getting it right, this is a service as in a process always running on your computer, not as in a cloud based compiler. The point is your program can dynamically call the compiler with additional source code to be compiled so your program can modify itself even though it's in a relatively static language like C#.
What is preventing anyone from doing just that with local compilers? I mean, its not like you can't switch from one compiler to another if one provider decides to be a douchebag and ban specific use. That will be their problem, and that's what competition is for. But I don't really see why that should be worse for 'services', at least in practice.
No, you're not getting it right, this is a service as in a process always running on your computer, not as in a cloud based compiler. The point is your program can dynamically call the compiler with additional source code to be compiled so your program can modify itself even though it's in a relatively static language like C#.
I'd mod your post +(Insightful/Informative)... my fault, thanks for pointing it out.
Questions raise, answers kill. Raise questions to stay alive.
Cross compiling is currently a bit of a bitch though. I would like a cloud compiler helping with building for different platforms at once. Provided you could freely download the compilers yourself of course.
I'm sorry. The title of this article is bad. SaaS has an established meaning and it does not necessary mean the services running in the background (as a service) on your PC, it means using remote services.
The article makes no mention where the actual compiler runs. If it runs remotely, are our fears are not unqualified.
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
Are you a troll, or just dim? If you don't understand anything the article speaks about, it might be a good idea to just not comment.
If I'd follow your advice:
1. I'd lose the chance to stand corrected - I'm not afraid to be in such a position, I'd suggest you to try sometime.
2. life may become a bit boring for you. I mean, you wouldn't have too many occasions to call someone a "troll or dim-witted". How would you like "good manner and menuet dancing" all the day everyday?
Questions raise, answers kill. Raise questions to stay alive.
Wait what?
I thought I was already using System.CodeDom.Compiler to dynamically create assemblies?
Also, converting code from one language to another isn't new in the slightest. Redgate's Reflector has been disassembling IL and displaying it in C#, and VB for ages. I'm sure there are open source equivalents too.
I fail to see what all the excitement is ... Unless they're able to give me an AST to mess with? Even then I might not be terribly interested.
It's quite possibly a terrible article. I mean C3! WTH?!
not 'service' as in 'zuckerberg/NSA world domination'
I don't think that's your fault, the summary is bad. Also I don't think it should be "C3", they are referring to C#. That mistake is in the article though, the summary just repeats it.
I would like a cloud compiler helping with building for different platforms at once. Provided you could freely download the compilers yourself of course.
Something like the OpenSuse build service?
PlusFive Slashdot reader for Android. Can post comments.
Pentium Processor Optimization Tools by Michael L. Schmit comes with a floppy that contains an "Optimizing Assembler". It doesn't actually optimize your code, but produces a formatted listing that gives the timing of each instruction, as well as pipeline stalls and the like. One can then use the listing to refactor the assembly source to be more efficient.
The book is long out of print but can easily be had used. It's also a good book for learning x86 assembly in general.
Request your free CD of my piano music.
If you Read The Fine Article (I know,.. you are not supposed to do this on Slashdot) you will see that it mentions C#. This is just the author who didn't push hard enough on the Shift-key and the submitter and the poster who didn't care to correct this error.
Doesn't change the fact, that a). you have the compiler "in your hands" for all of those platforms, and b). those were closed platforms since their beginning.
However, even if you get a free compiler like gcc, you either get the source (which you then have to compile yourself, shifting the problem to the compiler you use to compile it) or you get a precompiled version where you have to trust that whoever compiled it did not insert a backdoor.
Actually the only way to be completely sure without trusting anyone is to actually study the generated machine code (that's assuming you can trust your computer to faithfully execute that, of course). Of course in practice nobody would go that far (and few would even have the resources to do so), but instead there's one point where you put trust in (possibly the compiler+linker), and from there on you just go on.
Of course, another way would be to bootstrap by writing yourself an assembler in machine code, then a compiler for the source language of that compiler in assembly (using your self-written assembler), and then use that to compile the compiler you got in source (and to get an optimized compiler, compile the compiler with that compiler again). But again, few people have the resources to do so.
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables. If only one starting compiler has been compromised, or if both have been compromised independently, then the compiler executables thus generated will differ. Thus if the compiler executables generated that way are the same, they are very likely not compromised, or else there's a conspiracy and both original compilers contain the same malicious modification. The more separate compilers you add to the mix, the less likely a conspiracy becomes (and moreover if some compiler is really compromised, you'll also learn which one -- although you cannot exclude the possibility that the difference is just due to a "self-propagating bug" instead of due to malicious code, but then, neither is desired).
The Tao of math: The numbers you can count are not the real numbers.
The cloud compiler had yet another outage.
C3 might be a typo using a non US keyboard. For example, in order to type # in my keyboard layout ( http://img853.imageshack.us/img853/6585/kbdb.png ) , you should press AltGr + 3. If you miss AltGr you would type C3 instead of C#..
http://marketplace.eclipse.org/content/llvm-toolchain-eclipse-cdt
I wonder where all the trolls are which are always shouting "Mono is a cheap clone of .NET"...
It is a service to you, the developper, by providing you with information that normally only lives in the compiler. You can then you this data to have a better understanding of your code, how it is going to compile and various other operations.
"option strict on" ...
*facepalm*
throw new NoSignatureException();
you have much more ways to use the compiler. it still is on your desktop, still 100% in your control. but it's not a blackbox anymore, it's now something you can plug in own stuff, extend, reuse, etc.
Hmmm, I wonder where have I seen this before?
If you took the care to let your mouse hover on the link you'd see that the article's title was "Microsoft previews Compiler-as-a-Service software". The article's author used a very bad analogy-of-an-analogy and that's what's causing this confusion.
Given the dire state of technical and scientific journalism these days, nothing surprises me, although for technical journalism, this is hitting a new low.
So basically, he's describing a compiler which generates an annotated AST of the program being compiled? Actually, I've got no idea, because of shoddy, slipshod, lazy journalism.
Even for modern journalism, this is a piss poor effort. Whoever wrote this should be ashamed of themselves.
A great use case for something like this would be better merge conflict resolution. DVC Systems like git, hg etc work reasonably well for source code for simple changes, but concurrent refactorings in different branches are still a potential headache. If merge algorithms could get easy access to the semantics of the code they try to merge they could be a lot cleverer than just line based diffing. Does anyone know is something like this is already being worked on?
Jeez, these modern languages get more like xbase/Firefox every day.
VC6 (and even VB6) spit out data consumed by Microsofts stage-2 compiler (C2.exe)
Although I dont think such a thing exists yet, C3 could indicate another stage. Compiler research has been an ongoing thing at Microsoft, and the in-development Phoenix Framework continues to use a stage-2 compiler (still named c2.exe)
I believe the stage-2 compiler directly consumes abstract syntax tree's, performs optimizations (constant folding, etc..), generates 3AC intermediate code and performs more optimizations (peephole) and then (of course) generates object code.
"His name was James Damore."
Well, one way to increase trust would be to build the source-provided compiler with two different compilers
I'm glad to see someone else remembers David A. Wheeler's diverse double-compiling dissertation.
I mean, its not like you can't switch from one compiler to another if one provider decides to be a douchebag and ban specific use.
If a device's manufacturer won't digitally sign for execution any binary that isn't compiled with the manufacturer's own toolchain, developers of applications for that device can't switch.
Please see replies to c0lo's post.
Sounds like they kludged a re-invention of LISP onto an unsuitable language.
Yeah, but what isn't a reinvention of half of Common Lisp?
IIRC Apple's compiler is or was gcc, I seem to recall them moving to another (also open source?) compiler a while back. Regardless, Apple compilers are more or less standard C/C++/ObjC. The trick with iDevices is getting the compiled code onto the device. You can write, compile, and test IPhone apps all day with free tools on any Mac, or even a (questionably legal) Mac VM. Getting your code onto an iPhone requires either a license or cracking the device.
(It's a fine point I'll agree, but somewhat important. If Apple disappeared tomorrow you could still write and compile software for iDevices, and after jailbreaking them, get it onto the devices.)
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
You "new" it was better? I believe the word you are looking for is "knew".
Also, Mono is an implementation/compiler for .NET, not a replacement. So, if mono is better than (Visual Studios, and the MS .NET run time, I'm guessing you are referring to?) Then I'm guessing you don't want to kill .NET because that would also kill Mono, which is .NET.
To emphasize this point, I compile programs on both Mono and Visual Studios 2010/MS Runtime. I then run programs compiled on either system to run on the other.
Both are AMAZING pieces of work.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
You also can't trust food you didn't grow yourself. Doors and locks you didn't build yourself. People whom you haven't given birth to and watched from infancy. The level of paranoia represented by that quote is borderline hysteria. If you applied that mantra to any other area of your life you'd have to live in a sealed commune, by yourself or maybe with with a single (well vetted and not allowed to leave) life partner. Of course you can't trust any software you didn't create yourself... Like anything else in life you take some level of risk with nearly every decision you make. I'm not going to personally code review everything I put on my system on the off chance that Microsoft has inserted malware into it. Just like I'm not going to grow my own food on the off chance that Kraft suddenly decides to start poisoning every 20th bag of chips.
Indeed, were I to decide to do either of those things, I probably wouldn't have time to do the other, or much of anything else.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
I don't think you even really read the summary...
I don't think you read the (already classic?) Ken Thompson's Reflections on Trusting Trust
"You can't trust code that you did not totally create yourself." - if your binary compiler injects a backdoor in the object code, then even recompiling the compiler from source may not get you out of the woods.
Otherwise, let point to you the (in my opinion) relevant phrases in TFA:
Have you read all the code of your OS? Your compiler? Have your read the code of each compiler that was used in the chain, back to the very first one written in assembly/hex?
If not, then you are really not in much of a better position than you would be using a closed source compiler.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
It sounds a bit like an "all things to all men" Ada or PL/1 in vapourwear
You also can't trust food you didn't grow yourself. Doors and locks you didn't build yourself. People whom you haven't given birth to and watched from infancy. The level of paranoia represented by that quote is borderline hysteria. [a.s.o.]
If you'd stop to think a moment instead of rambling...
Speaking hypothetically, say I'd be a hacker... wouldn't it be nice to successfully attack "an always running compiler service", inject a little DLL there, and make all the applications you'd build and deploy in your organisation spy for me? Still think is hysterical paranoid? Or do you trust Microsoft to make this "compiler service" impervious?
Questions raise, answers kill. Raise questions to stay alive.
If not, then you are really not in much of a better position than you would be using a closed source compiler.
Well, even if I didn't, I'd argue I'm in a better position when using open source compilers... granted, not 100%.
And certainly more secure if using a compiler as a tool than a compiler as a service always running... on a Windows box.
Questions raise, answers kill. Raise questions to stay alive.
There's at least two points of failure in your counter here. First, what Microsoft is proposing here isn't a "software as a service" compiler, the title of the article is simply wrong. It's simply a compiler that provides a lot more access to the internals than current compilers (at least current MS compilers). Anything that a hacker could do to this compiler, he could do to a normal MS compiler. He'd have to have the same level of access to your box to modify this as he would to insert new code into your current copy of VS. Second, that's not what you said. What you said was that any compiler that you haven't coded and built yourself is untrustworthy. Which is completely true, but also completely paranoid.
It's always the case that you can only completely trust things which you have done yourself (assuming you made no errors, which is a whole nother ball of wax), but it's equally true that you can't live your life not trusting anything done by anyone else. Not if you want to live in society and participate in in human interaction in any case.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
From TFA: "It also adds dynamic typing to the statically typed C# and Visual Basic, allowing developers to add objects and new variables to a program on the fly."
So it turns VB/C# into...Obj-C!
*ducks*
I chose to end my comments, not with a rim shot, but a long decaying F#7sus4
I'd be more concerned with
(1) who is administrating the computer
(2) who is administrating the local network
(3) who is administrating the other computers on the local network
and the skills of this person/people, than if the computer is running windows and a compiler as OS service, or not.
On my home network, where I control everything, I'd run it.
On my work network, which is a bit too relaxed for my tastes, I probably wouldn't.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
I think Apple developed Clang as the frontend with LLVM as the backend instead of GCC. It is mostly GCC compatible but the main reason probably had to do with the licensing. Clang and LLVM are BSD style while GCC is GPL.
Well, there's spam egg sausage and spam, that's not got much spam in it.
On my work network, which is a bit too relaxed for my tastes, I probably wouldn't.
Exactly my point
Questions raise, answers kill. Raise questions to stay alive.
You're assuming that two different compilers would output identical binary images, but why would they? Different authors would implement different instructions in different ways. I'd expect that behavior only from a simple assembler.
From there maybe you could go on to compile a fairly simple reference compiler to compile your higher level languages, as you were discussing. But I doubt you could do a meaningful binary diff of the output of the Intel C compiler and gcc.
John
Have you read all the code of your OS? Your compiler? Have your read the code of each compiler that was used in the chain, back to the very first one written in assembly/hex?
You act as if limiting the number of vulnerabilities is a bad thing. Are we ever 100% secure? No. But that doesn't mean we should allow more vulnerabilities if we can help it. Will installing a good lock on my house protect it against all thieves? No. But if my current lock has a defect that allows it to be easily bypassed, I can replace it if I want.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Thanks, I'm in the comments just so I can avoid RTFA.
Wouldn't it be easier to just do what other languages do, and include an compiler in the runtime interpreter (the VM here)? Or Microsoft is too cool to imitate Lisp?
Rethinking email
The title on the article is misleading. The author is confusing the "Software as a Service" distribution model with the "Just In Time" (JIT) compilation model. The article subject is about how Microsoft, through the Roslyn architecture, is allowing SDK level access to the JIT compiler that runs the .NET applications on the host computer.
-Valen
Compile once, next thing you know, MS is launching a new app bearing great similarity to your program.
There's at least two points of failure in your counter here. First, what Microsoft is proposing here isn't a "software as a service" compiler, the title of the article is simply wrong.
Nope, this one is not: I didn't assume this service in the SaaS meaning (not this time anyway).
Anything that a hacker could do to this compiler, he could do to a normal MS compiler.
Not quite... lately it became easier to attack a running process than to "infect a file" (signed executables and whatnot), especially if that process is a server accepting request from other processes running under user privileges.
Second, that's not what you said. What you said was that any compiler that you haven't coded and built yourself is untrustworthy.
I didn't intend to say this, but to point the extra weakness: not only a file (the compiler executable image) but now an always running process as well (even if I admit, my intention wasn't clear).
Other than that, Ken's "thought experiment" is extremely paranoid, I agree... but one can choose to pick something that may be less extreme (and possibly valid, don't know yet how probably valid) from something paranoid-to-extreme.
Questions raise, answers kill. Raise questions to stay alive.
No, I'm not. I only assumed that two correctly working compilers would output functionally equivalent code (what I tacitly did assume was that the source-provided compiler doesn't invoke undefined behaviour, though). Note that I did not propose to compare the output of the two different compilers, but to compare the output of the one source provided compiler compiled with two different binary-provided compilers.
So say you have the source of gcc, and binary versions of Microsoft C and Borland C.
Step 1: You compile the gcc source code with Microsoft C (let's call the resulting binary vgcc).
Step 2: You compile the gcc source code with vgcc (let's call the resulting binaty gvgcc).
Step 3: You compile the gcc source code with Borland C (resulting in bgcc).
Step 4: You compile the gcc source code with bgcc (resulting in gbgcc).
Step 5: You compare gvgcc with gbgcc.
If both Microsoft C and Borland C correctly translate the gcc source code (and the gcc source code contains no undefined behaviour), then vgcc and bgcc, while not the same, have equivalent behaviour. Especially they both translate the gcc source code into the same executable. In other words, gvgcc and gbgcc must be binary identical.
The Tao of math: The numbers you can count are not the real numbers.
Deep!
Questions raise, answers kill. Raise questions to stay alive.
Doesn't mean this is a bad idea, it just means, like every other piece of computer tech, use with caution. On a Linux or BSD box, it's pretty damn easy to mimic a service if you don't need access to ports below 1024, and screen is installed, for example. With just those two caveats, there's a lot you can do that is really unpleasant. You don't even need a "service" to patch into.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
I don't know, in the 90's I used Universities computers to compile stuff all the time. Granted the software ran on their mainframes, and wasn't produced to run on the PC's of the time.
But other then making that point, i agree with you.
Be seeing you...
come to think of it, if it doesn't offer any network ports, I'm not sure I would mind running that service in my work environment either.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
I don't see the alternatives as a reduction of vulnerabilities in this case, unless you actually bother to look at and parse the code of the entire chain, or at some point hand recompile the binaries. I will never do this, and therefore, I gain no advantage.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
What part of adding another point of vulnerability isn't clear? Do you have to trust MS if you have Windows? Yes. But any code you write yourself is assumed not to have backdoors if you compiled it yourself. Having another party compile it for you adds a another layer of checks. Does the benefits outweigh the risks? Not in my book.
Well, there's spam egg sausage and spam, that's not got much spam in it.
I heard Compiler as a Service and thought at first, "Oh great, Microsoft feels the big threat by Google App Engine, and that Python is going to take all of their business, so they've created a Python killer."
I8-D
VB6: Getting our strict on since 1998!
I don't trust MS any more or less than I trust the developers of Linux and it's associated tools. So, swapping one for another doesn't really bother me. The question is - is the benefit from the tool worth the extra layer.
So, no, nothing about the statement is lacking in clarity.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
And assuming code you write/compile yourself has no back doors is idiotic. People doing that, and then selling it, is how many security issues come about..
And the compiler would still run on your machine, not a remote machine, so... You'd still be compiling it on your machine. Yes, it's a closed source compiler, but I don't want to waste years trying to comprehend the code clusterfuck that is GCC, so GCC is just as closed source for my purposes - I don't see an added risk.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
Service is a terrible word to describe this. TFA doesn't even use it except in the title. Compiler As An API. Compiler As A Library.
Of course, another way would be to bootstrap by writing yourself an assembler in machine code, then a compiler for the source language of that compiler in assembly (using your self-written assembler), and then use that to compile the compiler you got in source (and to get an optimized compiler, compile the compiler with that compiler again). But again, few people have the resources to do so.
I challenge that this is as hard as it sounds. The bootstrapping homebrew compiler doesn't have to be fast or efficient, and doesn't have to produce fast or efficient code, it only has to be *correct* the one time you use it. You'd then use it to compile gcc, which to my understanding is implemented using only C (not c++) features.
So time to bootstrap a correct C-compliant compiler? In my arrogance, I bet it could be done in 6 months by a few dudes in a garage. Which if you're in a field that needs bulletproof compiler trust, is a small investment.
You are awash in a sea of fiercely stated opinions. Obvious exits are: 'File->Quit', 'Reply', and 'Page Down'.
The brilliant part is that you don't even need a Trusting Trust attack for this. Since no one has access to anything except what the compiler spits out, you can't verify the compiler in any way. Granted, when you disassemble it (.NET makes it too easy), you should be able to notice the nasty things. Unless you compiled your disassembler with said compiler... But my point is that the compiler doesn't have to silently sabotage itself, because no one can get to it. It could, of course, silently sabotage other compilers and debugging tools.
And assuming code you write/compile yourself has no back doors is idiotic. People doing that, and then selling it, is how many security issues come about..
What? I am assuming that unless I have some sort of split personality like in Fight Club, I am not going to program a backdoor without my knowledge. Now I may not know the existence of every conceivable vulnerability but if you don't know the difference between the two, you should brush up on basic computer literacy.
And the compiler would still run on your machine, not a remote machine, so... You'd still be compiling it on your machine. Yes, it's a closed source compiler, but I don't want to waste years trying to comprehend the code clusterfuck that is GCC, so GCC is just as closed source for my purposes - I don't see an added risk.
Again, brush up on computers and read the article. Running compiler as a service may allow for execution of code that you do not intend. As an example, take the simple door lock which can be picked. Some door locks have numeric keypads that bypass the requirement of a physical key. That however opens up the lock to another point of attack.
Well, there's spam egg sausage and spam, that's not got much spam in it.
CHRIST, read the FUCKING article. By "service" it just means "library," not a network service. Do us all a favor and stay the fuck away from computers.
Two different compilers will obviously give you a different binary output. Even the same compiler will give you a different binary output, with different optimization flags or diffrerent architecture flags. Even with the same platform and optimization flags, a compiler might give you a different assembly for the same algorithm depending on specified alignments and/or instruction optimization.
And yeah, your post also assumes that the cpu itself where you run the compilers isn't flawed or tampered in any way.
You think it isn't very secure using a compiler as a service that is always running, but is it ok when you grab a binary of your open source compiler of preference from a mirror that is always running? And if you download it from source, do you check all the source code and related dependencies? and how about using a compiler on a operating system that is always running? (eg. a server?) How do you decide what is more trustable?
wait, I don't get your logic.
I think Microsoft understands the risks involved with allowing self-concealing malware to be released in its compiler - corporate death to the tune of >$230B. Nothing could possibly drive developers and customers from their platform faster than if such a thing were to happen. Indeed, it's in their vested interested to ensure that such a thing doesn't happen.
Does GCC have such a risk? Even if the project were to die because of such a thing what would anyone lose beyond a little pride?
yeah, it's just like plugins, however it's different in almost every conceivable way.
wait, the java compiler API will give you data-flow analysis on the code you give it?
no, the java compiler API is a thin wrapper around the compiler driver. little more than popen() with some support for file redirection.
Roslyn is a whole new beast.
just watch the video and learn.
guys, stop confusing this with SaaS, the Java compiler API, GCC plugins, etc...
Just watch the damn video!
To not repeat myself, I just refer you to my previous answer.
If you intend to compare the generated binaries, you of course use the same flags.
This is about comparing output from compiling the same source code.
Sure. However there you can do the same: Run the thing on several CPUs and compare. You could even go to a different platform and cross-compile to your destination platform.
The Tao of math: The numbers you can count are not the real numbers.
I think I'll stick with GCC/G++
Anons need not reply. Questions end with a question mark.
It wasn't this bad in the old days. But i agree, its past time to jump ship.. But where to go next?
---- Booth was a patriot ----
To not repeat myself, I just refer you to my previous answer. [slashdot.org]
That clarifies the subject but you assume that compilers are perfect pieces of immutable software - they aren't. In the example you gave, it is expectable for gcc to have specific defines or makefile rules for each compiler, resulting on a different binary. Also, there is the problem of external dependencies - the libc implementation of Microsoft and Borland are different, even when the api is the same.
If you intend to compare the generated binaries, you of course use the same flags.
It is usual for different compilers to have different flags, that do not translate for the same optimization.
This is about comparing output from compiling the same source code.
The same source code (the same algorithm) can/will give you different binary results on different compilers, due to instruction alignment, code branching and optimization.
Sure. However there you can do the same: Run the thing on several CPUs and compare. You could even go to a different platform and cross-compile to your destination platform.
Yeah, and when the results don't match, you don't know which version is tampered, so you're left at where you started.
Hell, it could be an interpreter.
I know tobacco is bad for you, so I smoke weed with crack.
While gcc may have compiler-specific defines, that hopefully doesn't modify the code generation part. But yes, this could in principle give a persistent difference (but it's very unlikely that this difference would be self-propagating, unless it was inserted intentionally, in which case it would make gcc not trustworthy anyway).
The library dependence is irrelevant, because the libc gcc-compiled programs (including gcc-compiled gcc) use is completely independent from the libc used by the compiler used to bootstrap gcc.
The options gcc accepts don't depend on the compiler used to bootstrap it, especially not on the options that compiler supports. Again, the compare is not of binaries generated by those compilers.
To the n-th time: I did not propose to compare binaries produced by the bootstrap compilers. Is this now clear?
I don't know which one was tampered with, right. But I know that most probably one was tampered with (or, less likely, one of them has a bug which propagates), which I wouldn't have known otherwise. So I know I should do more work to find out which one (e.g. by bootstrapping with a third compiler, and testing which of the now three final binaries agree). In other words, I'm not left at where I started (which is not knowing at all whether one of the compilers was tampered with).
The Tao of math: The numbers you can count are not the real numbers.
The library dependence is irrelevant, because the libc gcc-compiled programs (including gcc-compiled gcc) use is completely independent from the libc used by the compiler used to bootstrap gcc.
The library dependence is not relevant, not only because you can build static binaries, but also because different compilers can/usually have completely different runtime implementations - the scanf() you program potentially uses is completely different if compiled with gcc and with a borland compiler.
To the n-th time: I did not propose to compare binaries produced by the bootstrap compilers. Is this now clear?
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables.
So, you have gcc source, you compile it with visual studio and c++ builder, and then use the generated compilers to re-compile gcc and then compare the resulting binaries. You build gcc on visual studio with depencies of microsoft libc equivalent runtime, and with c++ builder, with borland's library. Now you have two somewhat different versions of the same compiler, but with completely different code paths (since each vendor implements their version of the C runtime). Also, because visual studio and c++ builder are different compilers, significant optimization differences (and subsequent bugs) may occur between the two builded binaries. And you propose that it is expected that both versions of gcc generate exactly the same binary, without any difference or glitch? You do have a lot of faith in software.