5 ms·

GCC has multiple, rich ASTs that you can access by modifying (and freely distributing) the source, or you can build a plugin that access the AST through the API

GCC has multiple, rich ASTs that you can access by modifying (and freely distributing) the source, or you can build a plugin that access the AST through the API. The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.

hga 12y ago
And the absolute certainty that without getting buy-in from RMS, the API would be constantly changed to frustrate such a AST dumping API. Unless GCC and/or EMACS (using LLVM) gets forked. Again.
- userbinator 12y ago
  True, but it takes effort to change the API, and even if they did something obfuscatory to it automatically with every new version, it wouldn't be all that hard to write something that parses GCC's source code or compiles programs specifically designed to exercise the right paths - and grabs the right bits automatically; a meta-AST-extractor. Similar techniques are already in use for automatically generating wrapper code to handle interfacing to unstable APIs, so it's definitely possible. I realise that such a system would probably scare the hell out of RMS, but he should know well enough that any obfuscatory changes are easily undone. In some ways, it's like the war between software protections and crackers - once the crackers developed tools to analyse and automatically bypass any local serial-number type protections, they solved the problem generally and DRM was forced to go online. I'd be interested to see what RMS would try if faced with such a solution...
  - hga 12y ago
    Indeed, but that route requires forking GNU Emacs and earning RMS's eternal hostility, along with his fanbois and girls. Which I can attest is no fun (I worked for UniPress on the EMACS that he illicitly forked GNU Emacs from, I went from a LMI Lisp Machine ally, and later roommate when he started GNU, to a "Software Hoarder" (note UniPress shipped their Emacs with undistributeble source)). It's a very big thing to split one or more communities like that, a potentially fatal thing, and this discussion has brought out that GNU Emacs is already losing a lot of mind share in the otherwise sort of natural for it C and C++ communities. One problem here is that RMS is not a C++ programmer (not an entirely unwise decision!), the languages he programs in, to the extent he does anymore, don't require this sort of thing, and apparently doesn't appreciate how this is a deal breaker for modern C++ programming. Or doesn't care, and how that's decreasing GCC mindshare as well. Because of this policy with GCC, 99.999% plus of the the academic mind share is with LLVM, and the only thing keeping it from taking over is it's relative paucity of backends.
  - mitchty 12y ago
    The only counter I have to "it wouldn't be all that hard to..." statements is that it is 2015, emacs can't even refactor things like xcode can do. And xcode is considered horrible by refactoring standards. If it were so easy it would have happened by now. One can only conclude gcc and its stewardship have no real desire to allow for such a thing to occur at all. Which means llvm will likely be the future for being able to handle large complex code bases and interactivity with editors like emacs or vim, or whatever else. Why we have to reparse c/c++ in every editor alive when the compiler already does such things and would just need to dump out the information needed to understand it is beyond me. I only see 2 solutions to this situation. First is gcc gets left behind as a backwater compiler that won't interact with the real world due to religious reasons. Second is it gets forked and like ecgs before it, the fork becomes the canonical version (likely ignored by the gnu/fsf folks as being a heathen fork or whatever).
    - hga 12y ago
      And GNU Emacs has to fork, absent getting RMS's buy-in, which is now not the way to bet. That's where the serious fork has to occur, I presume it could get by with LLVM output, right? Which of course would not be ideal if you're using GCC in your project.... Oh, if only they'd ignore the heathen fork of one of their marque projects. Not going to happen with EMACS, 99+% of its greatness is due to RMS by universal acclimation as of the very early '80s.
    - 72deluxe 12y ago
      Xcode cannot refactor C++ at all. Not in the slightest. It'll only do C and Obj-C. It's a pity because it is quite an enjoyable IDE to use every single day for my C++ work (I'm on 6.1.1, doesn't crash unlike the 6.0 series), but missing a feature like that stinks. Not that I've ever had need to use it so far, but still, it is a pity.

hga 12y ago

And the absolute certainty that without getting buy-in from RMS, the API would be constantly changed to frustrate such a AST dumping API. Unless GCC and/or EMACS (using LLVM) gets forked. Again.

userbinator 12y ago
True, but it takes effort to change the API, and even if they did something obfuscatory to it automatically with every new version, it wouldn't be all that hard to write something that parses GCC's source code or compiles programs specifically designed to exercise the right paths - and grabs the right bits automatically; a meta-AST-extractor. Similar techniques are already in use for automatically generating wrapper code to handle interfacing to unstable APIs, so it's definitely possible. I realise that such a system would probably scare the hell out of RMS, but he should know well enough that any obfuscatory changes are easily undone. In some ways, it's like the war between software protections and crackers - once the crackers developed tools to analyse and automatically bypass any local serial-number type protections, they solved the problem generally and DRM was forced to go online. I'd be interested to see what RMS would try if faced with such a solution...
- hga 12y ago
  Indeed, but that route requires forking GNU Emacs and earning RMS's eternal hostility, along with his fanbois and girls. Which I can attest is no fun (I worked for UniPress on the EMACS that he illicitly forked GNU Emacs from, I went from a LMI Lisp Machine ally, and later roommate when he started GNU, to a "Software Hoarder" (note UniPress shipped their Emacs with undistributeble source)). It's a very big thing to split one or more communities like that, a potentially fatal thing, and this discussion has brought out that GNU Emacs is already losing a lot of mind share in the otherwise sort of natural for it C and C++ communities. One problem here is that RMS is not a C++ programmer (not an entirely unwise decision!), the languages he programs in, to the extent he does anymore, don't require this sort of thing, and apparently doesn't appreciate how this is a deal breaker for modern C++ programming. Or doesn't care, and how that's decreasing GCC mindshare as well. Because of this policy with GCC, 99.999% plus of the the academic mind share is with LLVM, and the only thing keeping it from taking over is it's relative paucity of backends.
- mitchty 12y ago
  The only counter I have to "it wouldn't be all that hard to..." statements is that it is 2015, emacs can't even refactor things like xcode can do. And xcode is considered horrible by refactoring standards. If it were so easy it would have happened by now. One can only conclude gcc and its stewardship have no real desire to allow for such a thing to occur at all. Which means llvm will likely be the future for being able to handle large complex code bases and interactivity with editors like emacs or vim, or whatever else. Why we have to reparse c/c++ in every editor alive when the compiler already does such things and would just need to dump out the information needed to understand it is beyond me. I only see 2 solutions to this situation. First is gcc gets left behind as a backwater compiler that won't interact with the real world due to religious reasons. Second is it gets forked and like ecgs before it, the fork becomes the canonical version (likely ignored by the gnu/fsf folks as being a heathen fork or whatever).
  - hga 12y ago
    And GNU Emacs has to fork, absent getting RMS's buy-in, which is now not the way to bet. That's where the serious fork has to occur, I presume it could get by with LLVM output, right? Which of course would not be ideal if you're using GCC in your project.... Oh, if only they'd ignore the heathen fork of one of their marque projects. Not going to happen with EMACS, 99+% of its greatness is due to RMS by universal acclimation as of the very early '80s.
  - 72deluxe 12y ago
    Xcode cannot refactor C++ at all. Not in the slightest. It'll only do C and Obj-C. It's a pity because it is quite an enjoyable IDE to use every single day for my C++ work (I'm on 6.1.1, doesn't crash unlike the 6.0 series), but missing a feature like that stinks. Not that I've ever had need to use it so far, but still, it is a pity.