Page 1 of 1

Char string size limit still 64k?

Posted: Sun Jun 29, 2008 12:49 pm
by Roger Seiler
I had previously understood that in 32 bits we don't have the 64k size limit for a char string that we had in 16 bits. However, I saw in the xHarbour documentation for Memoread() that there still is a 64k size limit for a char string in xHarbour.

How about FWH - do we still have a 64k limit for a char string?

- Roger

Posted: Sun Jun 29, 2008 1:08 pm
by Rick Lipkin
Roger

I don't think there is a limit on a ( (x)harbour ) variable.. reason I say that is that I am doing fread's and frwites to variables appending them or extracting them from sql tables.. and the size of the binary documents are in the hundreds of kilobytes and megabytes ..

Rick Lipkin

Posted: Sun Jun 29, 2008 1:30 pm
by driessen
Roger,

Whether there is a limit or not, I don't know.

In FiveWin or Clipper 16 Bit, the limit was indeed 64K.

In Fivewin for Harbour/xHarbour the limit exceeds for sure 1 MB (I already used a variable containing more than 1 000 000 characters.

Posted: Sun Jun 29, 2008 1:49 pm
by nageswaragunupudi
Memoread function in both Harbour and xHarbour can read text files larger than 64K.

However functions like memoread and multiline Get seems have limitation of 32K

Posted: Sun Jun 29, 2008 3:34 pm
by Antonio Linares
Roger,

Here you have a working sample that shows that there is no limit (up to 4GB or available memory) for MemoRead():

Code: Select all

function Main()

   local cText := Replicate( "This is a test", 10000000 )

   MsgInfo( Len( cText ) )
   
   MemoWrit( "test.txt", cText )
   
   cText = "" // we empty the variable
   
   cText = MemoRead ( "test.txt" )
   
   MsgInfo( Len( cText ) )

return nil

Re: Char string size limit still 64k?

Posted: Sun Jun 29, 2008 4:29 pm
by Patrick Mast
Hello Roger,
Roger Seiler wrote:I had previously understood that in 32 bits we don't have the 64k size limit for a char string that we had in 16 bits. However, I saw in the xHarbour documentation for Memoread() that there still is a 64k size limit for a char string in xHarbour.
I just looke at our doc's at http://www.xharbour.com/xhdn/referenceg ... d&id=19161 but I can not see anything that says something about a limit. Where did you find the 4GB limit doc's?

Patrick

Posted: Sun Jun 29, 2008 5:42 pm
by Antonio Linares
Patrick,

4GB is the max amount of memory that can be addressed in 32 bits. Its not a Harbour limitation. Its a 32 bits architecture limitation.

Such limit does not exist in 64 bits, but again, it has another limit, though much higher.

Posted: Sun Jun 29, 2008 5:44 pm
by Roger Seiler
Thanks Antonio and others for your replies, which were reassuring.

Patrick, here is a quote from the \xhb\cod\xHarbour.chm functions section, the topic on Memoread()...

"• Return value:
MEMOREAD() returns the contents of a text file as a character string. The maximum file size that can be read is 65,535 characters (64K) -- the maximum size of a character string. If <cFile> cannot be found, MEMOREAD() returns a null string (""). "

So, I think that this text apparently needs to be corrected. But it's not at all surprising that in such a large help file, there may be just a few things that are a little off. On the whole, I know that the xHb documentation was a huge effort done very carefully.

- Roger

Posted: Sun Jun 29, 2008 11:15 pm
by Roger Seiler
Mystery solved. I was inadvertently looking at an obsolete version of the xHb help file. I actually have the current version of it here, but because it had a different file name than the old, it didn't overwrite the old when I updated. The current version does indeed have the correct information, in that the explanation for Memoread() makes no mention of any text size limit.

Sorry to waste everybody's time on this! I just need to pay more attention to the file date (in the name) when I open it up.

- Roger

Posted: Mon Jun 30, 2008 7:26 am
by Patrick Mast
Roger Seiler wrote:Mystery solved. I was inadvertently looking at an obsolete version of the xHb help file.
Ok! Thanks for the feedback Roger!

;-)

Patrick