Le dimanche 30 mars 2014, 18:19:32 Thorsten Glaser a écrit : > Oh, nice. I’ve found logs of bugs in, for example, GCC with it too, > but They never bothered to fix them, they just deprecated the code.
We'll try to avoid that but it seems quite clear that that will imply doing less checks to cover currently problematic cases. > Yes, surprisingly. Signals, for example on Linux/amd64, go from 1 to 64, > with valid kill() arguments and siglist entries ranging from 0 to 64, > where 0 is just never used. They shift the 1‥64 into 0‥63 for the signal > mask in order to not waste any. Ok, so a bug in tcc then. > > If they are NULL it doesn’t matter because mksh does "Signal %d" then. > It basically doesn’t dereference it. But it’s important that NSIG has > them, so a user can send those signals (they are real-time signals, > but still valid). Certainly, I was not implying there was a bug in mksh in the null case, just that I could see it confusing bound checking code in some way. > > >failed on the use of environ because the bound checking code cannot know > >the size of the valid area for environ and thus thinks an unsafe access is > >being > Hm. Well, “environ” is just a pointer to some (structured but not > easily bound) memory are. There *could* be code to scan for the > end, but that’d not perform. That's what I added in tcc for argv and the arge (third parameter of main). Look for the end of the array and register a bound region. But it doesn't work in the general case, tcc cannot know when considering an externally defined symbol if it's an array ended with a NULL value. We need a more generic solution. > > OK. If there is anything I should change in mksh (especially if it > could be a bug rather than a compiler workaround), feel free to say > so. (On the other hand, other compiler authors _did_ recommend to > just disable the bounds checking flag because their compilers’ code > for that didn’t manage to work, either.) We'll see but I'm afraid it'll have to wait for the release after the one coming soon. > > Thanks, much welcome! Are you also upstream? Yep. When I took over the maintainance of tcc I soon discovered that all of the bugs that were reported were upstream bug and that nobody would work on them if I didn't. So I started tackling just the bugs reported within Debian and eventually I became upstream. :) Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
