Re: [Tinycc-devel] Fixes to bcheck and how it works correctly

[grischka]

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