6 ms·
C2nim: A tool to translate ANSI C code to Nim
- keyle 6y agoThis has been going for ages I'm not sure why it's popular today? Any new breakthrough?
- Santosh83 6y agoI don't believe so. Just incremental improvements, no breakthrough. As for HN popularity, that is often a matter of chance. If a submission gets a few early upvotes and makes it to frontpage, it snowballs from there, often regardless of anything particularly noteworthy.
- fwsgonzo 6y agoWell, someone has to find it interesting - otherwise it will just be ignored. I assume.
- interfixus 6y agoProbably because the Nim folks just did their annual survey, and anyone participating would be reminded of C2Nim in at least one question.
- michaelsbradley 6y agoThere’s also nimterop: https://github.com/nimterop/nimterop https://github.com/nimterop/nimterop
- dataking 6y agoCool 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
- cb321 6y agoIt bears noting that the native Nim FFI is very "thin" & easy. E.g., at least for code anticipated to be compiled by the C backend, you can just declare the C function as a Nim proc (EDITTED to look nicer on mobile): proc csetvbuf(f: File, buf: pointer, mode: cint, size: csize): cint {.importc: "setvbuf", header: "stdio.h".} # ...intervening code... discard csetvbuf(stdout, nil, 0, 16384) c2nim is more helpful for larger C APIs with a lot of C structs and a wide set of entrypoints/API calls. For simple enough C code it can be used as a "starting point" to port the whole thing, but you will probably at least want to change things like a1, a2, etc. parameter names ("a" for "argument"). Nim has named arguments (like Python, f(x=2)) so such names are a bit more important. (Not that all code meant to be read by a human should not have good param names.)
- amelius 6y agoIt's meant for header files only.
- cb321 6y agoHeader-only is more applicable since you often only need declarations/Nim prototypes and a passL/C linkage to C libs where the C generated by Nim just calls into the C library. But if you wanted to port C to a "pure Nim" for whatever reasons (e.g. to also work at compile-time in the Nim VM or the Javascript backend) c2nim also works and can help. It may not work so well on fancier code, e.g. using a lot of cpp macros, etc. That tends to turn up more in .c files than .h files, but the boundary is obviously somewhat arbitrary.