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. ;)
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 ;) 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 _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel