5. Signed and Unsigned Data Types

Page 64

5. Signed and Unsigned Data Types

		In this chapter, we will take a close look at signed and unsigned data types. The topic is one of special importance in view of the prevalence of unsigned data types in the Win32 API, their general absence in Visual Basic, and the frequent difficulty of translating an unsigned value into its corresponding signed value.

	Signed and Unsigned Representations

		We have seen that VC++ and the Win32 API use both signed and unsigned integral data types, whereas VB has only one unsigned type the Byte data type. This can create a problem when an API function either expects or returns an unsigned data type. To understand just what is involved, we need to take a look at the internal workings of these data types and how they are represented in memory.

		The place to start is with some carefully defined terminology. We will couch our examples in terms of 16-bit words, but what we say applies equally to words of any length.

		A 16-bit word is simply a string of 16 binary bits, as in:

		w = 1111000011110000

		The key point is that a binary word is not a number until and unless it is given an interpretation as a number. It is just a string of bits.

		There are two common ways in which integers are represented as 16-bit words in most computers, including PCs: the unsigned representation is used to represent only nonnegative integers, and the two's complement signed representation is used to represent both negative and nonnegative integers. The latter is generally abbreviated in Microsoft's documentation as the signed representation, and we may do

Page 65

		so as well, although there are other types of signed representations (including the one's complement signed representation and the signed magnitude representation).

		It is important to understand that it is not the number itself that is signed or unsigned, it is the representation of the number as a binary word that is signed or unsigned. Numbers are neither signed nor unsigned. (A number can be positive, negative, or zero, but that is not the same thing as signed or unsigned all numbers have a sign.) Thus, the commonly used term signed integer is highly misleading. It should be read as signed representation of the integer. Nevertheless, this terminology is so common and so convenient that we will use it as well.

		When we declare an integer variable in Visual Basic and give it a value, as in:

		Dim i As Integer i = 5

		VB represents the integer using the two's complement signed representation. In this, we have no choice. Put another way when VB interprets a binary word as an integer, it does so using the two's complement binary representation of that word. Period. On the other hand, VC++ is more flexible, allowing us to choose the representation, as in:

		unsigned int ui; ui = 65000; int i;      // or signed int i; i = -30000;

		Here ui is an unsigned integer, that is, ui is represented in memory by VC++ as a (32-bit) binary word using the unsigned representation. On the other hand, i is a signed integer, that is, i is represented in memory using the two's complement signed representation.

	Why Two Different Representations?

		The reason for using an unsigned representation for integers is simple: by using an unsigned representation, we can represent larger positive integers than when using a signed representation. In exchange, we give up the ability to represent negative numbers.

		In particular, a 16-bit word that uses the two's complement signed representation can represent any integer in the range -32768 to 32767, whereas a 16-bit word that uses the unsigned representation can represent integers in the range 0 to 65535.

		There are compelling reasons to include both signed and unsigned representations in a programming language. It is probably not necessary to comment on the fact that a language would be hampered significantly if it could not represent negative numbers. On the other hand, an unsigned representation is useful for two reasons.

Page 66

		When we want to do arithmetic with positive numbers only, we get a larger range of values using an unsigned representation. This happens with addresses, for instance. If the word size of a computer is, say, 32 bits, then the most natural way to access all 232 possible memory addresses is by using an unsigned representation.

		Many numeric data types do not require the use of arithmetic. For instance, window handles are 32-bit numbers, but it makes no sense to add, subtract, or otherwise manipulate these numbers. They are strictly for identification purposes. Thus, the HANDLE data type is an unsigned long data type.

		It is time that we consider how the two's complement signed and unsigned interpretations actually work.

	Unsigned Representation

		When a 16-bit word is interpreted as unsigned, we simply count up from 0 in binary, as in the following list (the double arrow stands for ''represents"):

		0000 0000 0000 0000   0 0000 0000 0000 0001   1 0000 0000 0000 0010   2 . . . 0111 1111 1111 1111   2^15 - 1 = 32767 1000 0000 0000 0000   2^15 = 32768 . . . 1111 1111 1111 1111   2^16 - 1 = 65535

		Thus, the unsigned interpretation of 16-bit words allows us to represent all integers in the range 0 to 216-1=65535.

		As you probably know, each position in a binary number represents a power of 2, just as each position in a decimal number represents a power of 10. Table 5-1 is a template for creating unsigned representations of numbers. Each column represents a successive power of 2.

Table 5-1. A Template for Unsigned Representations
215	214	213	212	211	210	29	28	27	26	25	24	23	22	21	20
32768	16384	8192	4096	2048	1024	512	256	128	64	32	16	8	4	2	1

Page 67

		Table 5-2 shows an example of filling in this template to find the unsigned representation of the integer 50000. By successively subtracting powers of 2, starting with the largest one that fits, we arrive at:

		50000 = 32768 + 16384 + 512 + 256 + 64 + 16

		Next, we place these numbers in the third row of Table 5-2 and then put 1s underneath the numbers and 0s everywhere else. This gives a fourth row in Table 5-2, from which we get the unsigned representation:

		1100 0011 0101 0000   (unsigned) 50000

Table 5-2. An Unsigned Example: Representing 50000
215	214	213	212	211	210	29	28	27	26	25	24	23	22	21	20
32768	16384	8192	4096	2048	1024	512	256	128	64	32	16	8	4	2	1
32768	16384					512	256		64		16
1	1	0	0	0	0	1	1	0	1	0	1	0	0	0	0

	Signed Representation

		The strategy used in two's complement representation is to use the leftmost bit as an indicator of the sign of the number. The leftmost bit is called the sign bit. If the sign bit is a 0, the word is interpreted as a nonnegative integer. If the sign bit is 1, the number is interpreted as a negative integer:

		0xxx xxxx xxxx xxxx   nonnegative integer 1xxx xxxx xxxx xxxx   negative integer

		The Signed-Magnitude Representation

		The most obvious way to fill in the other bits is with the magnitude (or absolute value) of the number. For example, to represent the positive number 5, we would write:

		0000 0000 0000 0101   5

		since the binary representation of 5 is 101. For the negative number -5, we would simply change the sign bit:

		1000 0000 0000 0101   -5

		This method of representing both positive and negative numbers is called the signed-magnitude representation. It is very simple, but not very useful. One problem is that arithmetic with numbers represented in this way requires taking special cases based on the sign of the number. (Just try adding the binary representations for 5 and -5.) Also, there are two representations of the number 0 (+0 and -0):

		0000 0000 0000 0000   0 1000 0000 0000 0000   0

Page 68

		The Two's Complement Representation

		The two's complement representation is a much better approach and is used by most modern computers. It is easy to describe using a table. The analog of Table 5-1 for the two's complement signed interpretation is Table 5-3. The only difference between this table and Table 5-1 is the negative sign in the first column.

Table 5-3. A Template for Two's Complement Signed Representations
-215	214	213	212	211	210	29	28	27	26	25	24	23	22	21	21
-32768	16384	8192	4096	2048	1024	512	256	128	64	32	16	8	4	2	1

		To illustrate, Table 5-4 computes the signed representation of the integer -15536. Note that it is the same as the unsigned representation of 50000:

		1100 0011 0101 0000   (signed) -15536

Table 5-4. A Signed Example: Representing -15536
-215	214	213	212	211	210	29	28	27	26	25	24	23	22	21	20
-32768	16384	8192	4096	2048	1024	512	256	128	64	32	16	8	4	2	1
-32768	16384					512	256		64		16
1	1	0	0	0	0	1	1	0	1	0	1	0	0	0	0

		Since the only difference between Table 5-1 and Table 5-3 is that the numbers in the first column are negative, it is clear that a binary word with a sign bit of 0 represents the same integer using either the signed or the unsigned representation. Put another way, for integers in the range 0 to 32767, the two representations are identical.

		Also, since the sum of all of the numbers in the first row of Table 5-3 is -1, it is clear that a number is negative if and only if its sign bit is 1.

		Following is a list that shows how signed representation works. The list is ordered by increasing binary word. Note the sudden change from positive to negative integers in the middle of the list.

		0000 0000 0000 0000   0 0000 0000 0000 0001   1 0000 0000 0000 0010   2 . . . 0111 1111 1111 1111   2^15 - 1 = 32767 ' positive 1000 0000 0000 0000   -2^15 = -32768 ' negative 1000 0000 0000 0001   -2^15 + 1 = -32767

Page 69

		. . . 1111 1111 1111 1101   -3 1111 1111 1111 1110   -2 1111 1111 1111 1111   -1

		Why Is It Called Two's Complement?

		The reason that it is called this has to do with how we take the negative of a number that is represented in this form. Consider any number x written in two's complement form. Let us use the number in Table 5-4 (x = -15536):

		x   1100 0011 0101 0000

 

		Consider now the ordinary complement of this binary word; that is, the word obtained by changing all 0s to 1s and all 1s to 0s:

		xc   0011 1100 1010 1111

 

		Adding the two binary numbers gives:

		x + xc   1111 1111 1111 1111

 

		Note that this will be the result no matter what number we start with.

		But the binary word consisting of all 1s is the representation of the number -1, so we have:

		x + xc = -1

 

		from which it follows that:

		x + (xc + 1) = 0

 

		or:

		-x = xc + 1

 

		Thus, to get the negative of a number, we take the complement of its signed representation and then add 1. The resulting binary word is called the two's complement of the original binary word. Thus, to get the negative of a number that is represented in two's complement form, just take the two's complement of the number's binary representation..

	Translating Between Signed and Unsigned Representations

		Now we come to the heart of the matter translation between signed and unsigned representations. There are two issues to consider.

Page 70

		First, we may need to pass to an API function a number that is too large to fit in the corresponding VB signed data type. For instance, we may need to pass a 16-bit representation of a number in the upper "unsigned" range 32768 to 65535, say for example the number 50000. In VC++, we could simply write:

		unsigned short usVar; usVar = 50000;

		but in VB, the code:

		Dim iVar As Integer iVar = 5000

		will produce an Overflow runtime error. Note that we cannot use the code:

		Dim lVar As Long lVar = 50000

		because the function is expecting a 16-bit binary word.

		The second problem is the reverse. Suppose, for example, that an API function wants to return a 16-bit value in the range 32768 to 65535, such as 50000. Of course, the return value must be in a VB variable (since we are working in VB). But VB will interpret the variable as having a signed data type. In fact, it will interpret the number as -15536 because, as we have seen, this number has the same signed representation as the number 50000 has unsigned representation. So, the question is: "How do we recover the intended value?"

		These problems are easy to solve if we look at them in the correct light. Referring to Figure 5-1, the point is that VB will give a 16-bit binary word a signed interpretation, whereas Win32 will give it an unsigned interpretation (we are assuming here that Win32 is expecting or returning an unsigned short integer).

		Figure 5-1. Passing numbers between VB and Win32

		As in Figure 5-1, if w is a 16-bit binary word, let us write un(w) to denote the number obtained by thinking of w as an unsigned representation and si(w) as the number obtained by thinking of w as a signed representation. Thus, from our previous example in Table 5-2 and Table 5-4, we have:

Page 71

		un(1100 0011 0101 0000) = 50000 si(1100 0011 0101 0000) = -15536

		The point to keep in mind is that we are actually passing or receiving a binary word, not a number. VB and Win32 will both interpret this binary word as a number. The difficulty comes when they use different interpretations. VB uses the signed integer interpretation, and Win32 (we are assuming) uses the unsigned short integer interpretation.

		Thus, referring to Figure 5-1, in passing a number un(w) to an API function, we need to tell VB to pass the number si(w), since Win32 will interpret the binary word w that is actually passed (on the stack) as un(w). Conversely, in receiving a number, VB will see it as si(w), and we need to make the translation to si(w) which, by the way, will require using a larger VB data type to hold the value.

		So the whole problem boils down to translating between si(w) and un(w).

		We can see how to make these translations by noting that the only difference between Table 5-1 and Table 5-3 is the negative sign in the first column. Accordingly, there are two cases to consider.

		The first case is when the number si(w) is nonnegative or, equivalently, the number un(w) is in the lower half of the unsigned range (0 to 32767). (Whether we are passing or receiving, we will know one of these numbers!) In this case, the sign bit of w is 0. Hence, as we have seen:

		un(w) = si(w)

		Thus, in this case, we can use an ordinary VB integer to pass the number, and, in the other direction, the return value in a VB integer is the actual number (no changes are necessary).

		On the other hand, suppose that the number si(w) is negative or, equivalently, un(w) is in the upper range 32768 to 65535. In this case, the sign bit of w is 1. This bit, being in the first column of Table 5-4, contributes a total of 215 to the number un(w). On the other hand, it contributes a total of -215 to the number si(w). Since the contributions from all other columns are the same in both un(w) and si(w), subtracting out the contributions from the first column should produce equal values, that is:

		un(w) - 2^15 = si(w) - (-2^15)

		From this, a little algebra gives the two formulas:

		un(w) = si(w) + 2^16 si(w) = un(w) - 2^16

		These formulas are the key to all. We can now summarize.

Page 72

		Integers

		To pass a number un(w) in the range 0 to 65535 in a VB integer variable, put the number si(w) in the variable. In the other direction, if a VB integer variable receives a number and VB shows this number to be si(w), then the number passed is actually un(w). Here is the relationship between si(w) and un(w).

		For si(w) >= 0 or 0 <= un(w) <= 32767(= 215-1):

		un(w) = si(w)

		For si(w) < 0 or 32768 <= un(w) <= 65535 (= 216-1):

		un(w) = si(w) + 2^16 si(w) = un(w) - 2^16

		Sometimes a picture is worth a thousand words. Figure 5-2 shows the situation here. When a number lies in the range that is common to the signed and unsigned ranges (0 to 32767), then no changes are required when sending or receiving the number. To send a number in the upper unsigned range, subtract 216 to bring it into the signed range before sending the number. When receiving a number in the lower signed range, add 216 to get the actual number sent (in the unsigned range).

		Figure 5-2. Translating between signed and unsigned integers

		Longs

		Of course, the same principle applies to 32-bit longs.

		To pass a number un(w) in the range 0 to 232-1 in a VB long variable, put the number si(w) in the variable. In the other direction, if a VB long variable receives a number and VB shows this number to be si(w), then the number passed is actually un(w). Here is the relationship between si(w) and un(w):

Page 73

		For si(w) >= 0 or 0 <= un(w) <= 231-1:

		un(w) = si(w)

		For si(w) < 0 or 231 <= un(w) <= 232-1:

		un(w) = si(w) + 2^32 si(w) = un(w) - 2^32

		Figure 5-3 illustrates the translation process.

		Figure 5-3. Translating between signed and unsigned longs

		Bytes

		The situation for bytes is actually the reverse of that for integers and longs, since the VB Byte type is unsigned. The problem here occurs when the API function expects or returns a signed byte. Nevertheless, the principle is exactly the same.

		To pass a number si(w) in the range -128 to 127 in a VB byte variable, put the number un(w) in the variable. In the other direction, if a VB long variable receives a number and VB shows this number to be un(w), then the number passed is actually si(w). Here is the relationship between si(w) and un(w):

		For si(w) >= 0 or 0 <= un(w) <= 127 (=27-1):

		un(w) = si(w)

		For si(w) < 0 or 128 <= un(w) <= 255 (=28-1):

		un(w) = si(w) + 2^8 si(w) = un(w) - 2^8

		Figure 5-4 illustrates the translation process.

Page 74

		Figure 5-4. Translating signed and unsigned bytes

		Examples

		Here are some examples:

		Pass a number in the range 0 to 65535 that currently resides in a VB long variable lng to an API function with an unsigned short parameter:

		APIFunction(unsigned short param)

		with VB declaration:

		Declare   APIFunction(param As Integer)

		Solution:

		Dim param As Integer ' same size as the API function's parameter If lng >= 0 And lng <= 32767 Then    param = lng ElseIf lng >= 32768 And lng <= 65535 Then    param = CInt(lng - 2^16) Else    MsgBox "Value out of range for an unsigned short", vbCritical End If Call APIFunction(param)

		Pass a number in the range 0 to 232-1 that currently resides in a VB Currency variable cVar to an API function with an unsigned int or unsigned long parameter:

		APIFunction(unsigned int param)

		with VB declaration:

		Declare   APIFunction(param As Long)

		Solution

		Dim param As Long ' same size as the API function's parameter If cVar >= 0 And cVar <= 2^31 - 1 Then

Page 75

		param = cVar ElseIf cVar >= 2^31 And cVar <= 2^32 - 1 Then    param = CLng(cVar - 2^32) Else    MsgBox "Value out of range for an unsigned int", vbCritical End If Call APIFunction(param)

		In the next example, the situation is reversed the API function expects a signed value but the VB Byte data type is unsigned.

		Pass a number in the range -128 to 127 currently residing in a VB integer variable iVar to an API function with a signed char parameter (recall that the VB Byte type is unsigned):

		APIFunction(signed char param)

		with VB declaration:

		Declare   APIFunction(param As Byte)

		Solution:

		Dim param As Byte  ' same size as the API function's parameter if iVar >= 0 And iVar <= 127 Then    param = iVar ElseIf iVar >= -127 And iVar <= -1 Then    param = CByte(iVar + 2^8) End If Call APIFunction(param)

		Receive a number in the range 0 to 65535 in a VB integer variable iVar, from an API function that has an OUT parameter of type unsigned short:

		APIFunction(unsigned short param)

		with VB declaration:

		Declare   APIFunction(param As Integer)

		Solution:

		Dim lRealValue As Long      ' to hold the real value passed to VB If iVar >= -32768 And iVar <= -1 Then    lRealValue = CLng(iVar) + 2^16 ElseIf iVar >= 0 And iVar <= 32767 Then    lRealValue = CLng(iVar) End If

		Receive a number in the range 0 to 232-1 in a VB long variable lVar, from an API function that has an OUT parameter of type unsigned int:

		APIFunction(unsigned int param)

		with VB declaration:

		Declare   APIFunction(param As Long)

		Solution:

		Dim cRealValue As Currency ' to hold the real value passed to VB If lVar >= -2^31 And lVar <= -1 Then

Page 76

		cRealValue = CCur(lVar) + 2^32 ElseIf lVar >= 0 And lVar <= 2^31 - 1 Then    cRealValue = CCur(lVar) End If

		Receive a number in the range 0 to 255 in a VB byte variable bVar, from an API function that has an OUT parameter of type unsigned char:

		APIFunction(unsigned char param)

		with VB declaration:

		Declare   APIFunction(param As Byte)

		Solution:

		Dim iRealValue As Integer ' to hold the real value passed to VB If bVar >= -128 And bar <= -1 Then    iRealValue = CInt(bVar) + 128 ElseIf bVar >= 0 And bVar <= 127 Then    iRealValue = CInt(bVar) End If

	Converting Between Word Lengths

		Let us conclude our discussion of signed data types with the issue of converting between word lengths. This issue does not arise in API programming, so you may skip it if desired.

		To illustrate, suppose we have a number in the signed integer range -32768 to 32767 and we want to place it in a Long variable. What does VB do to the 16-bit signed representation of the number to get a 32-bit signed representation?

		If the number is positive, the answer is as expected VB just puts 16 additional 0s on the left. For instance,

		0000 0000 0000 1010   5 0000 0000 0000 0000 0000 0000 0000 1010   5

		On the other hand, what about a negative number?

		As an example, consider the negative number -32765, with signed representation:

		1000 0000 0000 0011   -32765

		Putting 16 0s on the left would produce a positive number, so this is not correct. Also, just changing the sign bit does not help the word:

		1000 0000 0000 0000 1000 0000 0000 0011

		represents:

		-2^31 + 2^15 + 2 + 1 = -2147450877

		which is certainly not -32765.

Page 77

		Suppose instead that we put 16 1s on the left, changing:

		1000 0000 0000 0011   -32765

		to:

		1111 1111 1111 1111 1000 0000 0000 0011   x

		To compute the value of x, we look at the contributions of the new bits.

		Since the original sign bit contributes -215 to the number -32765, but now contributes 215 to the number x, the increase in going from -32765 to x from this bit alone is:

		2 * (2^15) = 2^16

		In addition, the new 1s in positions 16 through 30 contribute an increase of:

		2^16 + 2^17 +   + 2^30

		to the value of x. Finally, the 31st bit, which is the new sign bit, contributes a negative quantity -231. Adding up all of the changes gives the net change in going from -32765 to x:

		2*2^15 + 2^16 + 2^17 +   + 2^30 - 2^31

		Some algebra that I guess you would prefer that I omit shows that this net increase is actually 0:

		2*2^15 + 2^16 + 2^17 +   + 2^30 - 2^31 = 0

		In other words, there is no change. Hence, x = -32765!

		We have shown that adding 16 1s on the left does not change the number. Put another way, to get the 32-bit signed representation of a negative number from the number's 16-bit signed representation, we just put 16 1s on the left.

		We can combine both cases (positive and negative numbers) as follows:

		To get the 32-bit signed representation of a number from the number's 16-bit signed representation, just copy the sign bit (whether it be a 0 or a 1) to the left 16 times. This process is called sign extension.