At 11:07 PM -0500 3/5/02, Bryan C. Warnock wrote:
>
>Three quick things:
>1) INTVALs and opcode_t > longs will now be even more suspect than what
>they were beforehand.
>2) Feel free to bicker with names. I don't think we've come to *any* sort
>of agreement with these, although we really, really, need to.
>3) I forget the third thing.
>4) But I thought of a fourth.
>5) I've now remembered the third thing: IIRC, ANSI C states that enums will
>fit within the smallest type (int or greater) that can hold the values. Is
>that actually correct, and does it state whether unsigned is preferred to
>signed for non-negative enums?
>6) Since I'm no longer constrained by "three" or "quick", I'm going size_t
>happy for a lot of memory-related storage. (That's good. No sense wasting
>the size or performance of an UINTVAL for strange values of UINTVAL.) I'm
>also using it in a couple other internal things (like the GC stat counters,
>seen here). Size and performance, again, and unpromotable to a bigint, so we
>know that we (theoretically) will wrap. However, size_t isn't the best
>choice for the type. (Not that there's anything wrong with size_t, just
>that it shouldn't be called size_t.) Any thoughts? I was thinking of just
>doing unsigned int, because, IIRC, int is usually the natural word size, and
>will be most efficient. Thoughts?
>7) I forgot what the fourth thing I thought of was while writing down the
>others. Sorry.
Applied, with a little fuzz and compensation made for some source
changes I'd done this morning. Thanks!
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
