On May 2, 2008, at 8:07 AM, William A. Rowe, Jr. wrote:
Christopher Key wrote:
The reason for wanting the (u)int8 types was primarily for
readabilty, i.e. to distinguish between whether you are
manipulating character data or numerical data. Moreover, there
are times where you specifically require an 8 bit uint, i.e. 255 +
1 == 0 etc.
+1 (be warned about magic 128/-128 values that vary between 2's-
compliment
and binary bitwise negation for apr_int8).
Let's simply vote, I'll give this a very short voting window so we
don't
block on the release. It can still happen late today.
I read Roy's objection as just that - an objection but not a veto.
Well, true, I merely object to the addition of unused and unnecessary
types.
Clients are fully capable of defining this themselves.
However, I do -1 (veto) the addition of
+else
+ # no known value for 8 bit type
+ AC_ERROR([could not detect a 8-bit integer type])
and
+else
+ # no known value for 16 bit type
+ AC_ERROR([could not detect a 16-bit integer type])
and
+else
+ # no known value for 32 bit type
+ AC_ERROR([could not detect a 32-bit integer type])
for reasons already stated. APR may add meaningless cruft if it likes,
but I will not have the httpd platforms reduced because of it.
....Roy
