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

[Tony Hosking]

Fact.  New versions of m3core won't be able to build with old tools/libraries.  We have to live with that.

On 15 Jan 2010, at 16:34, Jay K wrote:

> We were in a state where neither m3core nor cm3/m3quake could be built with old tools/libraries.
> That is more ok for m3core, less ok for cm3/m3quake.
> As well, m3core also couldn't be built with recent but slightly old compiler.
>     See, I didn't remove the use of LONGINT, just the use of VAL(LONGINT, INTEGER).
>     As well, maybe cm3/m3quake couldn't be built with recent tools/libraries.
>  
>  
> The sysutils/m3quake/cm3 changes should stand?
> Ok removing "32" from the name and letting it return >4GB on 64bit platforms.
> But I think either it can't use libm3.File.T.status().size, OR we have to
> make status().size more compatible such as by introducing statusL or sizeL.
> 32bit code wouldn't see >4GB file sizes unless actively changed.
> Maybe not a bad idea.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 15 Jan 2010 16:17:15 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3devel] WebFile/QScanner use of File.T.status().size (64bit file size on 32bit platform)
> 
> On 15 Jan 2010, at 15:57, Jay K wrote:
> 
> 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?
> 
> RIght.  Except we should not try to maintain compatibility between among trunk versions.  If you want to build as of a particular version then use libraries that match that version.
> 
> My next set of commits for LONGCARD make this even more critical because the library has hardwired stuff that that makes it require a particular version of the compiler to compile it.  ;-)
> 
> 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?
> 
> Yes.
> 
> It seems a tough situation..the compiler is otherwise I believe
> very compatible with old compiler/libm3.
> 
> It very soon will not be.
> 
>  
>  
>  - 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/m3devel/attachments/20100115/af5911bb/attachment-0002.html>