On Mon, 23 Mar 1998, Chris G. Demetriou wrote:
> However, the original goal was to come up with an expression which
> yields the correct result _and_ which avoids the gcc "comparison is
> always 1 due to limited range of data type" warning.

[Warning: I am wearing my C language lawyer hat.] 

> (val >= 0) yields the correct result, but causes that warning.

Right.

> ((int)val >= 0) yields the correct result, but also causes that
> warning.

No, it fails in implementations that have sizeof(char) == sizeof(int).

> (((int)val & 0x100) == 0) also yields the correct result (for machines
> where char is 8 bits -- i.e. all machines that NetBSD supports), but
> does not cause that warning.  The expression is still always true on
> unsigned-char machines, but gcc isn't sophisticated enough to catch
> it.

Right.  But (in this case and the one above), I hate to see nonportable
code where portable code would do the job and is no less efficient.  If
you must write code that depends on implementation-specific features
such as (sizeof(char) < sizeof(int)) or (CHAR_BITS == 8), then please at
least document those assumptions in big XXX comments.

> I'd love to hear a better suggestion, but...  8-)

static __inline__ int
__objc_code_char (unsigned char* buf, char val)
{
#if (CHAR_MIN == 0)
  /* char is unsigned on this machine */
    return __objc_code_unsigned_char (buf, val);
#else
  /* char is signed on this machine */
  if (val >= 0)
    return __objc_code_unsigned_char (buf, val);
  else
    {
      buf[0] = _B_NINT|_B_SIGN|0x01;
      buf[1] = -val;
      return 2;
    }
#endif
}

--apb (Alan Barrett)