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

[Jay K]

That is ok but what about building new cm3/m3quake/sysutils packages with old tools/libraries?

They previously never used LONGINT, including converting LONGINT to INTEGER.

*I* changed that, not you.

But then I decided it was a mistake.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 15 Jan 2010 17:08:08 -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)

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/m3commit/attachments/20100115/a8b5a71b/attachment-0002.html>