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

[James Dunne]

On 5/22/05, Peter Fröhlich <address@hidden> wrote:
> Hi all,
> 
> On May 20, 2005, at 14:03, James Dunne wrote:
> 
> > 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.
> 
> I might be wrong, but isn't this a *basic* problem in languages that
> are not garbage collected? You simply can't allow basic operators that
> can be composed into arbitrary expressions to allocate memory, you'll
> always have a leak if you do.
> 

You are absolutely correct, Peter.  This is the problem I've been
fighting against.  If you check my Developer Blog site (link in
previous e-mail), I've recently converted the entire implementation
over to using a struct CString * approach instead of plain old char
*s.  The CString keeps the length of the string data, as well as the
total allocated data (allowable for resizing and appending to
strings).  It always keeps a pointer to the string data and
reallocates that.

> What am I missing, i.e. how can you ensure you're leak-free? Especially
> in light of stuff like
>
>    s1 ~ f(t1 ~ t2) ~ s2

Exactly; I can't.  This is why I proposed to only allow the ~= form of
the operator as opposed to writing expressions like you mentioned
above.  In my new implementation, I've encouraged the user to do
something like this:

CString *s1 = cstr_new("Hello", 32);  // define "Hello" with 32 spaces
before and after
CString *s2 = cstr_new(", World", 0); // define ", World" with 0 space
initial headroom (still expandable, but not expected to)

s1 ~= s2;

printf("%s\n", s1.data);

Again, refer to my blog post as it defines all you need to know about
CString and the API functions that act upon it.  For reference: 
http://jamesdunne.blogspot.com/ .  The direct link to the post is: 
http://jamesdunne.blogspot.com/2005/05/c-string-concatenation-operator.html

My example implementation of the _cstr_cstr_cat function call that the
~ operator is translated into assumes that the first CString * operand
is to be modified and the return value is just a copy of that same
CString *.  This is done because I will soon disallow lone usage of ~
and only continue with ~=.  The problem then becomes prepending
strings easily.

> 
> where you have an intervening function call as well (which, I assume,
> you don't rule out)? Of course in this case some blame could be put on
> the author of f() as well...
>

Blame can always easily be placed on anyone participating :)

> Peter
> 
> PS: And of course in this light the interface of malloc() is hopelessly
> flawed, it should not return a pointer but rather write the address it
> allocated to a pointer that is passed in by reference...

Not sure why this could make a difference...  Could you explain how
this could help?

> --
> Peter H. Froehlich <><><><><><> http://www.cs.ucr.edu/~phf/
> OpenPGP: ABC2 9BCC 1445 86E9 4D59  F532 A8B2 BFAE 342B E9D9
> 
> 
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 

-- 
Regards,
James Dunne