On Thursday 04 October 2001 11:40 pm, Gibbs Tanton - tgibbs wrote: > >Well, that obviously should be MAX_whatever and MIN_whatever. > >But sufficient for now, since that's probably a configure thing. > > Yes and No. If our inline constants are always going to be 32 bits then 2 > ** 31 should always work (of course I shouldn't do it in such an ugly > fastion, but a constant should work ).
Are they going to be 32 bits, or are they going to be opcode_t? opcode_t is *at least* 32 bits. If opcode_t is 64 bits, do we want to inline 2**63, or 2**31? > > >> This required a change in two of the integer tests as 0xdeadbeef and > >> 0xa0b0c0d0 were both bigger than 2 ** 31. > >> Basically, this patch ensures that all code in the pack file is of > > size > > >> opcode_t (except the constant table which is in string(char) or double > >> format). It also has the (size_t) casts where pointers are converted > > to > > >> integers. > > > >FWIW, size_t != size of pointers everywhere. (But you're probably > >safe.) > > No, but it should always be AT LEAST as big as a pointer. That is all > that matters, we only have problems when it is smaller. (See below.) size_t needs only be able to represent the maximum value it will need to hold. (Most likely, the size of the largest array possible.) On some older segmented platforms, that was smaller than the addressable space. In Intel Real 16 mode, IIRC (which I probably don't), pointers are 32 bit, but size_t is 16.. > > >> a FLOATVAL constant without having to type 0.0 > >> 9.) Changed (INTVAL) casts in memory.c, register.h, and strnative.c to > >> (size_t) casts just in case sizeof(INTVAL) < sizeof(void*); > > > >!=, not <. (If you cast back, for instance.) > > Unless we do something horribly wrong, then the cast back shouldn't be a > problem becuase the value cast back will fit in a void*. If there's something that can go horribly wrong, it's inevitable that I will find a way to do it. :-) > > >> 10.) integer.t had 0xdeadbeef changed to 0xdeadbee and 0xa0b0c0d0 to > >> 0xa0b0c0d for signed 32 bit compatability. > >> Any and all feedback is appreciated. > >> > >> NOTE: I apologize if this patch is still not what is wanted; I don't > > want > > >> to enforce anything I decide to code on parrot, but I thought it might > > be > > >> easier to comment on the patch if it were already coded. If this > > isn't > > >> wanted, I will continue to change it until it is :) > > > >I'm still not sure about size_t, but nothing standard had been added > >until > >recently. It's probably universal enough to be safe, but we may want to > > > >just find a type the same size as a pointer and roll our own just to be > >safe. > > I think size_t will be safe; however, I understand your hesitation. I can > replace size_t with a typedefed type ( perhaps ptrcast_t ) and then have > it typedefed with size_t to begin with. That way, we can easily change it > when we decide what we want to do. Does that sound OK? Sure, as long as I'm only being paranoid and not stupid about it. -- Bryan C. Warnock [EMAIL PROTECTED]
