[M3commit] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)

[Jay K]

I at least did move the hacks to one place.

I agree it isn't nice.

This is due to my changes, not yours -- changing File.T.status().size to LONGINT.

There's no way to use that in the "compiler" and still support old compiler/libm3, right?

Ok now that I centralized it to sysutils?

 

 

Leave status() alone as using INTEGER and introduce statusL()?

 

 

Or leave size alone and introduce sizeL?

 That's not a complete solution because you have to set size to something.

  -1 if it doesn't fit?

 

 

Or just get past the bootstrapping and put it back using VAL?

It seems a tough situation..the compiler is otherwise I believe

very compatible with old compiler/libm3.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 10:13:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Jay, all of these changes seem unnecessary (and worse, clutter the source with a variety of hacks). I had no problem building against both versions of m3core and libm3 in order to bootstrap a new compiler. What is going on here?
> 
> On 15 Jan 2010, at 14:41, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/01/15 14:41:00
> > 
> > Modified files:
> > cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3 
> > m3makefile 
> > Added files:
> > cm3/m3-sys/m3quake/src/: QScannerC.c 
> > 
> > Log message:
> > m3quake also can't use libm3 File.T.status().size and be compatible
> > with both old and new libm3 (INTEGER vs. LONGINT)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100115/870c16bb/attachment-0002.html>