Thomas Preud'homme dixit:
>I took a look at this bug recently. Thanks to this, two bugs have been fixed
>in
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.
>I managed to go a bit further by changing the condition on NSIG from <= NSIG
>to < NSIG in inittraps in histrap.c Are you sure it should be <=NSIG?
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.
>I could go even further by changing NSIG to 32 when I noticed that the entries
>from 32 to 64 are null (I thought it could confuse tcc in some way). It 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).
>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.
>The problem in histtrap seems to be the same. When computing the address
>of histtraps[i] at some point the bound checking code returns -2 (access to
>unsafe zone) which once multiplied by i * sizeof(void *) goes in the end of
>address space and causes a crash. I'll think how to solve this.
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.)
>Anyway, I just wanted to tell you that we are trying to fix this and we didn't
>forget that bug.
Thanks, much welcome! Are you also upstream?
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
