tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()


From: Sean Conner
Subject: Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()
Date: Wed, 22 Aug 2012 16:57:13 -0400
User-agent: Mutt/1.4.1i

It was thus said that the Great grischka once stated:
> Sean Conner wrote:
> >It was thus said that the Great grischka once stated:
> >>Sean Conner wrote:
> >>>>As to the patch I think that
> >>>>   +    s1->runtime_mem = NULL;
> >>>>would break tcc_relocate and I don't see why you need it.
> >>> I did that so that the call to tcc_delete() wouldn't crash when it tried
> >>>to free s->runtime_mem that might contain a garbage value (since
> >>>tcc_relocate_ex() would never set that field).  Good thing too, because
> >>>tcc_new() *might not* be initializing NULL pointers correctly [1].
> >>Well, from my point of view that line would not fix tcc_new
> >>but cause a memory leak for tcc_relocate.
> >
> >  I did a bit more work.  The assignment of s1->runtime_mem to NULL does 
> >  not
> >lead to any memory leaks.  On systems where the NULL pointer *is* all zeros
> >(most, if not all, modern systems I am aware of) removing the assignment
> >does not cause a crash (since the memory used to store the state is zeroed
> >out).  On systems where the NULL pointer *IS NOT* all zeros [1], removing
> >the assignment *WILL CRASH*.  Not "might crash", *WILL CRASH*. [2]
> 
> Well, behavior of free for invalid values is undefined.  It might
> crash but might as well restart the computer or do nothing or ...

  Which is why I assigned NULL to s1->runtime_mem.  Calling free(NULL) does
nothing (as specified).

> Anyway, features and bugs are not different in that both are generated
> as side-effects from the written lines of code.  I can't help and sorry
> and all but the feature that you wrote here is ... a 100% state of the
> art memory leak.

  What I want to know is *how* is what I did a memory leak?  Yes, there's a
memory leak if I allocate the memory and call tcc_relocate_ex() and never
free said memory, but that's a case where *I* want to control the memory
used for the code/data segments.  In that case, I do *NOT* want tcc_delete()
to delete the code/data segments thus created.  

  You seem to be assuming that the programmer can't be trusted and thus, you
want to do everything for the programmer.  I have a difference of opinion on
this.

  But again, how is what I did a memory leak?

> However the most grave argument against this line is that it breaks
> assumptions, here the assumption that tcc_new *DOES* the right thing
> with initialization.  You never ever put code to implement safety
> precaution against the failure of assumptions made elsewhere in the
> same program.
> 
> See, on a system where memset doesn't clear pointers tcc or libtcc
> would fail already in tcc_new.  It would never reach your "safety"
> line.

  My assumption of your assumption is that TCC will never be used for cross
compilation.  That may not always be the case (on the other hand, the
situation may never come up).

  -spc




reply via email to

[Prev in Thread] Current Thread [Next in Thread]