[Mono-devel-list] [Patch] RReader not to rely on bounds checking

[Willibald Krenn]

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
Willi

P.S.: You really don't want to know how much time I need for writing 
emails like this.