A scheme or haskell(or c++) program that is compiled with a compiler that uses c as an intermediate form is still a scheme/haskell/c++ program. Even if the intermediate code is analyzed by a static analyzer or humans(especially if it's not modified, but possibly to some extent even if the intermediate code is slightly modified or used by other intermediate code written by hand) the source language is the actual language.
no, autogenerated C code means someone (maybe a build script) runs a Python script that generates a bunch of C files, and then the C compiler picks up those files. Those C files exist in the file tree and may be human readable.
C files are being generated, not machine code, by some script. Fairly common practice in large C projects that have complex/heavily conditionals where you're less likely to introduce incorrect conditions if you let program logic printf your code to a file
You can tell gcc to keep around the assembly files it generates and it is human readable, does it mean that C code compiled with gcc is actually written in assembly? Is the litmus that they are caching the intermediates of the compilation on disk instead of throwing them away and regenerating them every time?
You are now officially being disingenuous. Stop it. Read the posts and apply thinking skills. A auto-generated means (by definition) programmers did not write the C code, they wrote something else.
By ANALOGY (here is a definition with examples, since you seem to not understand analogy: http://grammar.about.com/od/rhetoricstyle/f/qanalogy07.htm ), the argument the Curiosity code was written in C, is the same as me saying my C code is actually written in machine code (raw high and low bits), since the machine code is generated by my compiler, even though I actually wrote C.
FILE *out;
out = fopen("crc32.h", "w");
if (out == NULL) return;
fprintf(out, "/* crc32.h -- tables for rapid CRC calculation\n");
fprintf(out, " * Generated automatically by crc32.c\n */\n\n");
fprintf(out, "local const unsigned long FAR ");
fprintf(out, "crc_table[TBLS][256] =\n{\n {\n");
write_table(out, crc_table[0]);
This example is in zlib. Whether it's the 'pretty' way to do it or not, this isn't a terribly uncommon thing to see in C code bases. In this case, this is a lookup table. Code is a tool, "auto-generating" code is not some fancy term, all it means is a button was pushed and a bunch of code came out the other end. Having worked on large C codebases, we used to do this sort of stuff all the time. Maybe it's the dumb way of doing things, but when you work on large teams that all maintain the same codebase, dumb and readable is more important than cleverness sometimes.
This doesn't change the point the top-level comment was making. Even if some N lines of C spit out some M lines of different C (hopefully with N < M), the actual code written by the programmers is the code that should be counted, not the generated code.
In the case you describe, the language used to generate the code is C, but the concept doesnt change. This is where you are being disingenuous by means of pointless pedantry.
most of the time line counts are just .c and .h in the file tree, and the generated files to often end up in the file tree and repository.
I'm merely speaking from my own extensive experience in dealing with large C code bases. What you are calling disingenuous and pedantic is ignoring where the hand-wavy line count numbers actually come from. The tend to come from code that is actually checked into the repository which, whether you like it or not, can include large amounts of auto-generated code.
