[M3devel] fault reports beyond 100mill lines?

[Michael Richter]

Why the magic number of 100,000,000?  Why not 4 billion, say?

On 7 July 2010 04:35, Jay K <jay.krell at cornell.edu> wrote:

>
> I'm pretty settled on silently losing line numbers over 100 million.
> If the host and target are 64 bits it preserves far more.
> If someone produces such a file, and it compiles and runs, but gets a
> runtime error in their code on the wrong line, they can claim they found a
> compiler bug...
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Date: Tue, 6 Jul 2010 20:21:08 +0000
> > Subject: [M3devel] fault reports beyond 100mill lines?
> >
> >
> > It appears that if a file has over around 100 million lines, that fault
> reports (nil deref, subrange out of bounds, etc.) get the wrong line number.
> > Leave it as ("qualit of implementation"?) or fail an assertion in the
> compiler earlier (leaving anyone with a huge file kind of stuck (generated?)
> or, unlikely, expand the range?
> > The line number is in an integer along with a 5 bit fault code.
> >   We could also allow much larger numbers on 64bit targets.
> >
> >
> > This is just because there's a "FIXME" comment in parse.c.
> > The code is basically right and I'm adding comments and perhaps
> assertions.
> > Certainly we can assert that the fault code is in range.
> >
> >
> > I think I prefer silently losing bits in the line number, or conveting it
> to 0 if it is out of bounds or pinning it to maxint.
> >   Though it'd be maxint  / 32 which is less "special" looking if someone
> ever saw it.. though the runtime could
> >   report maxint / 32 as maxint.
> >
> >  - Jay
> >
> >
>
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100707/1a773da0/attachment-0002.html>