[Mono-devel-list] [Patch] RReader not to rely on bounds checking
Willibald.Krenn at gmx.at
Mon Jan 31 10:14:22 EST 2005
Lluis Sanchez schrieb:
> Bounds checking will always work. It is a requirement of the CLR.
Well, the reason I 'found' this code was that bc did not work. You know
what error I got?
"System.Runtime.Remoting.RemotingException: Configuration file
'/usr/etc/mono/1.0/machine.config' could not be loaded: Expected element"
Despite the fact that the parser did not say what element was expected
on what line and what elements were on parser stack that time, it took
quite a while of _not_ intended debugging to finally see RReader was the
culprit (and not the config file or parser). It took some hours more to
finally realize that indeed bc wasn't working correctly...
> I don't think abcremoval can optimize this case.
I'm just checking. Unfortunately I found yet aother bug
(MonoMethod->signature == null where it's not expected to be null) that
prevents me from using monodis...
>> So we'd still have one 'cmp'
>>but no exception would be raised in case pos >= len.
> this should never happen anyway if the configuration file is valid.
The exception will always be thrown, because in my rev. of 'mcs' code,
the Parser reads in until RReader.Read returns -1..
> I just don't want to lose time reviewing patches that don't fix real and
> reproducible bugs. But since now I've already lost that time (and even
> more time writing this mail), you can commit the patch if you want.
You're talking about losing time? How much time did I lose just because
my test program (I need for my cont. optimization work) did not run and
mono did not return any meaningful error message? If the catch would not
have swallowed a SigSegv, it would have been a piece of cake, but so..
Lluis, I have no problem if you clearly say 'no, this won't go in,
because I don't like it'.
I'll commit it, if it turns out that abcrem handles this case
P.S.: You really don't want to know how much time I need for writing
emails like this.
More information about the Mono-devel-list