4 ms·
Cool project. One of the best decisions we made for C2Rust was to use clang to parse C code (which is also the recommended approach by the author of Corrode). I
by dataking 6y ago
Cool project. One of the best decisions we made for C2Rust was to use clang to parse C code (which is also the recommended approach by the author of Corrode). It looks like C2nim is rolling its own C parser for now; that's eventually going to become a limitation as the project expands to cover more of C.
- pjmlp 6y agoActually I see having a hard dependency on clang also as a limitation.
- logicchains 6y agoI predict Clang in 10 years will be like Google today compared to Google 10 years ago: a bloated goliath that nobody likes any more but for which there aren't any alternatives.
- CJefferson 6y agoOne problem is parsing C inevitably means parsing headers, which often means parsing system headers, and they tend to be full of non-standard C weirdness (and have new things added all the time) which in practice are often understood by clang and gcc and not a lot else.
- cb321 6y agoWhile what you say is true, it's impact need not be so prohibitive as to box you in to clang/gcc. TinyCC/tcc [1] parses almost all C99 with a 3900 line tccpp.c and 8000 line tccgen.c. As long as extensions are careful to stay "syntactically isolated", the complexity of parsing C need not explode. E.g., at least on Linux where glibc headers are very gcc-tilted, the only extension tcc really needs is that __attribute__(()) stuff (maybe 1 or 2 other "just ignore this stuff" things). While there can always be edge cases that are broken, I use tcc daily on Linux without issue. So, I would encourage people to not view C as an untamable complexity monster or be captive to prevailing implementations. { C++ is, of course, a more unfortunate story in this and so many other regards :-) } [1] https://github.com/TinyCC/TinyCC https://github.com/TinyCC/TinyCC
- flohofwoe 6y agoLinux is a bit of a special case, unfortunately on other operating systems system headers must not be written in standard C or in C at all (e.g. Objective-C on macOS, or Windows SDK headers requiring Microsoft-specific extensions or even a C++ compiler).
- pjmlp 6y agoI see moving away from C as fortunely, and if it wasn't for uprising of Linux based FOSS, we would be much further down that line, given how all desktop stacks were focusing on C++ during the late 90s. Rust will have Rust/WinRT on Windows, Nim can also go down that path for example.
- kevin_thibedeau 6y agoBut then we'd be stuck with fossilized 90's era C++ stacks.
- pjmlp 6y agoWinRT and Qt are hardly fossilized.
- cb321 6y agoI did use TinyC/tcc successfully on Windows a few times without any header problems, but it was very admittedly a far less rigorous test and may well have not touched any headers with MS-specific extensions. I never tried it on MacOS, though it would be unsurprising if that NeXT/Mach-O derived object format were unsupported. Anyway, the world of C extensions has mostly seemed syntactically judicious/surgical. That's more just cultural, not guaranteed by anything, but it makes me suggest (without knowing) that MS extensions would probably not be hard to support without complexity explosion. Apple, on the other hand, doing their own chips now and Swift and just generally being even more of a closed system..They seem most likely to make that hard someday if they ever think they can make more money by not supporting POSIX-like programs. :-( { EDIT - there will likely always be some demand for/a way to create C callable wrappers/headers for system services, though. So, I don't think that it's crazy to hold out hope that this will remain possible/not too bad for the foreseeable future. }