Re: tcc

Adam Borowski wrote:
> On Wed, Mar 11, 2009 at 11:21:08PM +0100, Stefano Zacchiroli wrote:
>> On Wed, Mar 11, 2009 at 01:14:03PM +0100, Bill Allombert wrote:
>>> I fail to see the difference between a BDF-to-PCF converter and a C compiler
>>> that will discard comments from the C source files. Yet we do not generally
>>> ship C source code in binary packages.
>> This is not the right analogy. A C source file by itself cannot be run
>> without having been compiled
> 
> I guess you haven't seen the Real Men's only true scripting language.
> 
> apt-get install tcc
> chmod a+x my-masterpiece-script.c
> (prepend #!/usr/bin/tcc -run)
> ./my-masterpiece-script.c

It is not real C  ;-)

few assumptions on compiled language doesn't allow you to
interpret a compiled language (and usually also the contrary).
Few programs use such assumptions, but anyway...

E.g. in C:
programmers could expect that a valid and compiled program
could fail only on certain points.
On interpreters you usually cannot expect such behaviour.

E.g. a program which lock data, modify important data (with
security implication), using a complex mathematical function,
which maybe overflows the minimal "compiler resouces" as guarantee
by C standard, as number of block, identifiers, swith cases, ...)

On compiled version: the compiler could fail (no guarantee on
such limits), but in the other case, inside the lock, the important
data are parsed as expected, and will not fail.

On interpreted version: the interpret execute the lock,
start to modify important data and ... oops memory limit
(e.g. to many loops, blocks, parenthesis), and the
program stop in an unexpected point.


So we need to be carefully using a language in a different
environment.
If there is real interest and demand on interpreted C, I think

C language could be modified to allow (in an expected way) both
compiled and interpreted program to be runs, but it is not yet the case.

ciao
	cate