Re: [Tinycc-devel] C language modification using TinyCC - problems

[James Dunne]

Thanks Evan for your help.  I should've mentioned that I've tried all
you've said and have printed the pointer value for result in the
function call.  I found the problem.  It was in my code in TinyCC - I
should've used REG_IRET for the vtop->r value instead of RC_IRET.  It
now works!

Yes, I'm aware of the memory allocation problem and am hoping to
migrate it over to using struct CString *s instead of char *s, just
like in TinyCC's code.  Since the struct gives you both the length of
the string, the amount of memory allocated to the string, and the
string pointer, reallocating memory for it is trivial and can be
freed.

The problem is at it's worst when multiple concatenations are strung
together as in s1 ~ s2 ~ s3.  You lose the reference to the char *
allocated by s1 ~ s2 since it is fed into ~ s3.  Perhaps this should
be disallowed and only ~= should exist.  This should help a bit, since
you can assume that the user is always modifying the lvalue, and you
can reallocate the memory for the lvalue.  The handle to it is never
lost.  Still there is the problem with reallocating memory to string
literals... But that can be fixed by migrating to struct CString *s.

On 5/20/05, Evan Langlois <address@hidden> wrote:
> 
> > int main(int argc, char **argv) {
> >       char    *s1 = "hi ";
> >       char    *s2 = "neat!";
> >       char    *s3 = "poo";
> >
> >       printf("s1 %p\n", s1);
> >       printf("s2 %p\n", s2);
> >       printf("s3 %p\n", s3);
> >
> >       s3 = s1 ~ s2;   // line 20
> >
> >       printf("s1 %p\n", s1);
> >       printf("s2 %p\n", s2);
> >       printf("s3 %p\n", s3);
> >
> >       return 0;
> > }
> >
> > My outputs are the following:
> >
> > ex6.c:20: warning: assignment makes pointer from integer without a cast
> > s1 0x807eb6c
> > s2 0x807eb70
> > s3 0x807eb76
> > hi
> > neat!
> 
> looks okay so far.
> 
> > hi neat!
> 
> Again, its fine.
> > s1 0x807eb6c
> > s2 0x807eb70
> > s3 0xbffff5cc
> 
> Are you sure s3 is wrong?  Have you printed the string itself?
> You aren't printing the value of the pointer "result" which is
> over-writing the value of "s3".  Since result is malloc'd it makes sense
> that the pointer (the new s3) might be very different from the
> statically allocated strings.
> 
> The real problem I see is that you are implicitly allocating storage
> that must be explicitly deallocated.  This "extension" might introduce
> extra allocation errors and more places to keep track of pointers.  Of
> course, if you can get boehms-gc to link with tcc generated code, then
> you are all set.  Contrary to popular belief, I've found that garbage
> collected programs can often run FASTER than either explicit memory
> management and even faster than calling malloc() and never free()ing the
> storage!
>

You should take a look at the D programming language.  This is exactly
what it does.  My feelings on garbage collectors are mixed, at best. 
It is convenient to develop with them, but really they produce more
problems than they solve in my experience - especially with
multi-threaded apps.  This is why I wanted to extend the C language's
feature set without garbage collection.

> > What am I doing wrong?  s3's value looks wrong and produces the same
> > garbage string each time the program runs.  As you can see, __concat
> 
> Your test program doesn't show the garbage string.
> 
> > is getting the parameters correct and successfully concatenates them.
> > The generated code, however, does not process the return type
> > correctly.  I hope it's a small, easy fix!  =)
> 
> Maybe stack corruption?
> 
> 

The problem was actually the generated code not retrieving the return
value of the function.  It was fixed by changing RC_IRET to REG_IRET. 
I hope this proves to be a useful lesson to anyone else who might run
into this bug.

Also, in my code, I've removed that damn arrow (->) operator.  All
field access is done using dot (.) operator, regardless of whether or
not the struct needs dereferencing.

Check out my developer blog at http://jamesdunne.blogspot.com/ as it
explains my patches and some other neat projects I've been working on.

-- 
Regards,
James Dunne