> pochas wrote: > > > >So if I 'ask' the compiler for an array with ten elements, do I get ten or > >eleven elements in the array ?? > > > > > > > >So confused, it hurts my brain > > > > > > >Pete aka "Mr. Gumby" > > > > > zero thru 10 = 11 elements > > > > > Best, > > > > > -STAZ ~)~ > > > > Well, while we're on this scintillating topic, could we pursue it just > > one > > step further, to its obstreperous conclusion in the land of MacHandle? > > > > When we iterate myHandle& = fn newhandle(0), well, how many bites 'ave we > > purchased? > > > Hi, > my understanding is that you are asking for a block in memory with 0 byte in > length for the data. > The block has a blockheader whose size is just a little less than 2 billion > terabytes since it is 12 bytes according to Inside Mac, if the information I get > is not outdated. This header must be padded out to 16 bytes. > In fact, I think you can test the following piece of code: > DIM memory&,x&,i& > memory& = FN FreeMem > FOR i& = 1 TO 100 > x& = FN NewHandle(0) > NEXT > memory& = memory& - FN FreeMem > > PRINT memory&/100 > > On my computer the result gives 32 bytes per block (that's why I think my > information was not valid any longer) Mine too (see below). > > > > > And, meLaddie, what about sethandlesize(myHandle&, 0) , now? Did we > > really get rid of the little rascal? Or is there still a token of a wee > > byte there that could hold a single character? > > With the SetHandleSize call you are telling how much memory the data will occupy > in that block. > So with a size of 0 byte, you don't get rid of the block itself but just the > data that previously fit in the block.. Even if you push the thing very hard > with both hands, I think you cannot put a single (even tiny) char in that room. > Don't take my words for granted it is just how I feel the things are going. > > Hope this helps anyway. > > Cheers > > Alain I decided to look into this. By dimensioning handles to adjacent memory then loading the handles with strings, then forcing system memory block moves with sethandlesize(), I found out that apparently when you request a handle the system allocates 16 bytes you can't use without crashing (header block) plus the memory you requested plus 0 to 15 bytes of usable memory to fill the block to a 16 byte boundry, except when you request size 0 the system gives you 16 bytes of usable memory anyway (plus the 16 "header" bytes = 32 as you said). I was able to request a handle sized zero, load it with a 16 byte string, then force system memory moves, and the 16 bytes were copied to the new locations. If I tried to blockmove 17 bytes into the handle, the system crashed. I must have been writing over block headers, or some such. So, if you're numbering bytes from zero, the safe size to use with the newhandle function is one more than the number of the highest numbered byte, i.e. the count of the number of bytes desired. But if you specify a size of zero, 16 bytes will be reserved anyway, which in principle could be used to hold data. This is in contrast to dimensioning arrays, where you supply the number of the highest numbered element, as Staz indicated. Regards, Charles P.