Re: [Tinycc-devel] Tinycc bugs/feedback

[fabrice . bellard]

Quoting Greg Haerr <address@hidden>:

> Fabrice,
>     I just learned about TinyCC and I must say I'm extremely
> impressed.
> You've done an amazing job.
> 
> Of course, given that I also love small things I thought I'd give it a
> check-out and see how it compiles up Microwindows...  

Note the TinyCC does not generate good code. Main goal are simplicity and speed.
In the futur I may update the code generator so that even if the code is not a
lot more optimized it is smaller.

> Following
> are a few possible bugs and comments from my experience.  I've
> only dedicated a half hour so far so bear with me.
> 
> source: tcc-0.9.10
> 
> tcc issues
> 
> 1. In perusing the tcc source, is it correct that tctok.h, line 54
> reads:
> 
> DEF(TOK_strcpy, "strlen")
> 
> Shouldn't that be "strcpy"?  This would only be an issue if
> CONFIG_TCC_BCHECK is turned on.

Good remark :-)


> 2. My system didn't happen to have the directory 
> /usr/local/share/man in existence.  This failed "make install".
> Perhaps docs should be the last item in the install, or
> have the install make the directory.  Of course, "man tcc"
> still doesn't work on my (older) RH system since it doesn't
> seem to check /usr/local/share/man.

It was for the debian packet. I'll revert it to /usr/local/man.

> Microwindows compilation issues
> source: microwindows-0.89pre9 CVS
> 
> I modified Microwindows config file, Arch.rules and Makefile.rules
> to remove things that gcc accepts like -O, -Wall.  Following
> are the results.  All results do compile with gcc, admittedly
> I realize they're not necessarily strictly ANSI.
> 
> 3. The preprocessor directive #error is used in a couple of
> places.  Tcc doesn't recognize it at all, and the #if/#endif
> processing
> nesting gets screwed up.  This caused some havoc.  In one
> case the #error was terminated by a \ with more text on the
> next line.  Solution: //#error

Strange because #error should be well supported.

> 4. #ifdef linux is not defined by tcc, but is by gcc.  Fix, "tcc
> -Dlinux=1"?

OK I'll add it.

> 5. local functions aren't supported. (I'm rewriting this code now in
> mwin)

It seems possible to add them as a gcc extension. I'll look at it, but no
promise for next release.

> 6. non-constant auto-declarations aren't allowed "int array[size];"
> I'm rewriting this code now.

TCC will support it (needed for full C99 compatibility), but not in the next
release.

> 7. tcc segfaulted when compiling engine/devdraw.c. Haven't
> figured this one out yet, I'll send more info.
>
> Great job, I'm going to get tcc to compile up Microwindows,
> and it will really be small!!
> 
> I don't know if there's been much discussion on what libc features
> and functions are required for tcc, but I'd like to get into this
> a bit.  Has this been discussed at much length?  I see some
> folks are trying to get uClibc running with tcc.  What I'm interested
> in is just what's needed to get tcc self-hosting, and also to compile
> Microwindows.  (malloc, and a little file i/o.  I've got a very small
> stdio I wrote 15 years ago that could work here...)

I did not look the libc issue.  There are already at least 4 small libcs for
linux : ucLibc, dietlibc, klibc and newlib.

An interesting issue would be to have a totally safe libc when using bound
checking. It would also be interesting to have a '-safe' option to generate
'safe' code like java. With a few fixes in bound checking and modified C
libraries it would be possible.

Fabrice.