On Wed, Dec 12, 2012 at 04:19:50PM +0100, grischka wrote: > Kirill Smelkov wrote: > >Overall I liked original vstack and vtop assignment rules, only it had > >to deal with initial vstack-1 somehow. And documentation about vstack > >and vtop and everything else stays the same. I don't insist my way is > >good 100% good though... > > Yeah, that is the problem: we like the original and still it seems that > we need to change it. > > Anyway, I tried both: > 1) stay with pre-increment vtop, but replace any "vstack" by > "vstack + 1" in place. > > Conclusion: doable but ruins the original design, somehow. > > 2) switch to post-increment vtop, using macros also: > > ST_DATA SValue vstack[VSTACK_SIZE], *vstack_top; > #define vtop (vstack_top - 1) > #define vdrop(n) (vstack_top -= n) > > and replace all "vtop--" by "vdrop(1)" > > Conclusion: pervasive but doable, does not waste vstack[0], > might be slightly slower because all access "vtop->xxx" > now includes offset -1. vtop as macro is not that nice but > has the advantage that it can't be lvalue, so that one can > find any real vstack modification more easily by searching > vdrop/vpop. > > But I guess I like your solution best, for now. ;)
I too, first tried similiar steps, then come to vstack macro :) > >Let's imagine that bcheck checks pointers only on dereference. Then > >let's consider following: > > > > int a[10], b[10]; > > > >If we have p=&b[0], then do p--, how do we know whether there is no > >bounds error for p? p points to correct memory &a[9], but it is out of > >bounds - it started from b and crossed the limit. > > > >That's why in lib/bcheck pointers are checked not only on indir, but > >also on add. And that's why we have to pay the price. Btw - maybe "not > >ansi" comment was there for a reason... > > Yes, that was I wondered: How can it track relation between some > specific pointer variable and the associated memory region? So as > you explain the trick (and price) is to watch (and restrict) pointer > arithmetics. > > I'm figuring that there could be a way to just "memorize" pointer > arithmetics and postpone the check until real access later. But that > might be a bigger project. > > >Nevermind. Here is what I've learned about how lib/bcheck.c works: > > > >Memory is treated as regions. Every region could be either [...] > > Great. Please feel encouraged to put such details (also restrictions, > supported platforms etc.) into tcc-doc.html. In order to help the > "1st class citizen bcheck" theme, I mean ;) Aaaargh, no time!!! I mean I could possibly do it in between distant-future and never... > By the way the issue reminds me of some email that I received from > Fabrice once in 2007, where he wrote: > > >Hi, > > > [1] > >For your information I working on a new code generator for QEMU. I am > >designing > >it so that it is possible to use it in TCC, but it will require a non > >negligible > >amount of work ! > > > [2] > >Another point is that I realized that the bound check region algorithm used > >in > >TCC is completely broken (the code to search the region associated to a > >pointer > >does not work in all cases). I think the only way to make it work reliably is > >to tag each allocated byte with one bit. > > > [3] > >A last point is that I wonder whether it would be good to change the TCC > >license > >to BSD like. Would you agree on that ? > > > >Regards, > > > >Fabrice. > > As to [1] "TCG", see also this (Fabrice's reply below): > http://landley.net/notes.html#14-05-2012 > > As to [2] "bcheck", I didn't plan to fix it so I didn't ask what exactly > he meant. Maybe you know better, by now. > > As to [3] "BSD", I think I was trying to ask on this list but the echo > wasn't like pursuing and the question is probably over by now. > > Also I think that LGPL probably does fit quite well our "mob" approach > because as quite some people (except maybe Rob L.) would agree: If one > wanted to lift tinycc onto a more say professionally attractive level, > it would be easier to rewrite some substantial parts than to fiddle > with existing complications. > > Apropos, some people appear to do Android Apps using arm_tcc to run C > on the fly in the phone: > https://play.google.com/store/apps/details?id=com.n0n3m4.droidc&hl=en > > Thanks, > > --- grischka On Wed, Dec 12, 2012 at 08:49:34PM +0100, grischka wrote: > Kirill Smelkov wrote: > >Let's imagine that bcheck checks pointers only on dereference. Then > >let's consider following: > > > > int a[10], b[10]; > > > >If we have p=&b[0], then do p--, how do we know whether there is no > >bounds error for p? p points to correct memory &a[9], but it is out of > >bounds - it started from b and crossed the limit. > > > >That's why in lib/bcheck pointers are checked not only on indir, but > >also on add. And that's why we have to pay the price. Btw - maybe "not > >ansi" comment was there for a reason... > > Actually in bcheck.c:__bound_ptr_add there appears to be a special case > for code such as > > int a[10], *p; > for (p = a; p < a + 10; ++p) > *p = p - a; > > to ignore the off by one pointer addition at end of region. Now what > about the also not so uncommon reverse case > > int a[10], *p; > for (p = a + 10; --p >= a;) > *p = p - a; > > I don't think I would like to change that just for bcheck. Then again > if that were allowed, the vtop stuff in TCC could stay as it was, I > suppose? Grischka, I agree bcheck has its limitations in desing and in order to operate correctly on every C code should be reworked. But sorry, I can't digg into this - as it is now I'm not using it - it was just a weekend etude to fix what was broken... Sorry, Kirill _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
