I've noticed that DWord and QWord values when written to the Registry supposed to be Signed Integers, not Unsigned. This code will throw an exception if value is UInt64 or UInt32:
registryKey.SetValue(name, value);
According to MSDN DWORD is a 32-bit unsigned integer (range: 0 through 4294967295 decimal) https://msdn.microsoft.com/en-us/library/cc230318.aspx
So, to write new DWORD value to the Registry I need to cast it to signed integer like so:
UInt32 unsignedValue = (UInt32)someValue;
Int32 signedValue = (Int32)unsignedValue;
registryKey.SetValue(name, signedValue);
Passing unsigned value to SetValue method will throw an exception.
Am I missing something or I just being retarded?
For historical reasons, the .NET API/libraries is normally "signed" instead of being "signed + unsigned".
But in the end, a signed int and a unsigned int both occupy the same memory space, and there is no special handling done for negative values. So you can do as you said: cast the unsigned value to signed, write it with SetValue and then if you look at the value in Regedit you'll see that it was written "unsigned".
Note that if your program is compiled in "checked" mode, a more correct code would be:
uint unsignedValue = ... // Your original value
int signedValue = unchecked((int)unsignedValue);
registryKey.SetValue(name, signedValue);
Because in "checked" mode casting between int and uint can throw an exception if the conversion isn't possible.
Note that as written here:
This overload of SetValue stores 64-bit integers as strings (RegistryValueKind.String). To store 64-bit numbers as RegistryValueKind.QWord values, use the SetValue(String, Object, RegistryValueKind) overload that specifies RegistryValueKind.
Clearly you'll have to do the same handling for signed-unsigned.
From the RegistryKey.SetValue page' example:
// Numeric values that cannot be interpreted as DWord (int) values
// are stored as strings.
It seems the stored values are signed ints or strings.
Related
As per the MSDN article: https://msdn.microsoft.com/en-us/library/8s682k58%28v=vs.80%29.aspx
Explicit conversion is required by some compilers to support narrowing
conversions..
Based on the statements made in the above msdn link, is it safe to say that
Converting int to uint is narrowing conversion
Also,
Converting uint to int is narrowing conversion
?
Converting an integral or floating point type from signed to unsigned and vice-versa is neither a narrowing nor a widening conversion, since the number of bits used to store it remains unchanged.
Instead, it is a change of representation and can utterly change the number (e.g. signed -1 is converted to unsigned 0xffffffff).
In fact, if you use unchecked arithmetic:
unchecked
{
int x = -1;
uint y = (uint) x;
int z = (int) y;
Debug.Assert(x == z); // Will succeed for all x.
uint a = 0xffffffff;
int b = (int) a;
uint c = (uint) b;
Debug.Assert(a == c); // Will succeed for all a.
}
So a round trip works in both directions, which proves that narrowing does not occur in either direction.
Narrowing and widening only applies to integral and floating point types where a different number of bits are used to store one or more parts of the number.
However, because the number's value can be changed, you must cast to make such a conversion, to ensure that you don't do it accidentally.
It is not narrowing, but you must still be explicit. Both can hold values that the other doesn't have. int can hold negative values, which uint can't and uint can hold values greater than 2147483647, which is the maximum value for an int.
However, both int and uint use 32 bits (= 4 bytes) to hold information.
When you convert an int to a byte, you will lose information, because a byte can only hold 8 bits.
Converting between int and uint doesn't lose any bits, but the bits have a different meaning. (in 50% of the cases)
You must be explicit about it to indicate that you know what you are doing. It will prevent mistakes that would be caused by an implicit cast.
Here's a piece of code for obtaining the time when a .NET assembly was built. Note this line:
int secondsSince1970 = System.BitConverter.ToInt32(b, i + c_LinkerTimestampOffset);
this code extracts the TimeDateStamp member of IMAGE_FILE_HEADER structure that is stored inside the assembly. The structure is defined as follows:
typedef struct _IMAGE_FILE_HEADER {
WORD Machine;
WORD NumberOfSections;
DWORD TimeDateStamp;
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
WORD SizeOfOptionalHeader;
WORD Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
and DWORD is defined as follows:
typedef unsigned long DWORD;
and the struct description says that TimeDateStamp is a number of seconds since an arbitrary moment in the past, so it can't be negative.
Why does the C# code use signed type int to store that unsigned value?
It is because unsigned int is not a CLS compliant variable type and all .NET libraries should follow Common Language Specification.
More info about CLS compliance:
http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx
The pinvoke documentation fro GetExitCodeProcess shows exit codes returned as unsigned integers (uint). How do I handle a process with negative exit code values? Is LPDWORD correctly assigned to uint or is that a bug in pinvoke doc?
pinvoke doc:
http://www.pinvoke.net/default.aspx/kernel32.getexitcodeprocess
win32 api doc:
http://msdn.microsoft.com/en-us/library/ms683189(v=vs.85).aspx
DWORD in unsigned integer.
A 32-bit unsigned integer. The range is 0 through 4294967295 decimal.
This type is declared in WinDef.h as follows:
typedef unsigned long DWORD;
No bug here.
In my C# source code I may have declared integers as:
int i = 5;
or
Int32 i = 5;
In the currently prevalent 32-bit world they are equivalent. However, as we move into a 64-bit world, am I correct in saying that the following will become the same?
int i = 5;
Int64 i = 5;
No. The C# specification rigidly defines that int is an alias for System.Int32 with exactly 32 bits. Changing this would be a major breaking change.
The int keyword in C# is defined as an alias for the System.Int32 type and this is (judging by the name) meant to be a 32-bit integer. To the specification:
CLI specification section 8.2.2 (Built-in value and reference types) has a table with the following:
System.Int32 - Signed 32-bit integer
C# specification section 8.2.1 (Predefined types) has a similar table:
int - 32-bit signed integral type
This guarantees that both System.Int32 in CLR and int in C# will always be 32-bit.
Will sizeof(testInt) ever be 8?
No, sizeof(testInt) is an error. testInt is a local variable. The sizeof operator requires a type as its argument. This will never be 8 because it will always be an error.
VS2010 compiles a c# managed integer as 4 bytes, even on a 64 bit machine.
Correct. I note that section 18.5.8 of the C# specification defines sizeof(int) as being the compile-time constant 4. That is, when you say sizeof(int) the compiler simply replaces that with 4; it is just as if you'd said "4" in the source code.
Does anyone know if/when the time will come that a standard "int" in C# will be 64 bits?
Never. Section 4.1.4 of the C# specification states that "int" is a synonym for "System.Int32".
If what you want is a "pointer-sized integer" then use IntPtr. An IntPtr changes its size on different architectures.
int is always synonymous with Int32 on all platforms.
It's very unlikely that Microsoft will change that in the future, as it would break lots of existing code that assumes int is 32-bits.
I think what you may be confused by is that int is an alias for Int32 so it will always be 4 bytes, but IntPtr is suppose to match the word size of the CPU architecture so it will be 4 bytes on a 32-bit system and 8 bytes on a 64-bit system.
According to the C# specification ECMA-334, section "11.1.4 Simple Types", the reserved word int will be aliased to System.Int32. Since this is in the specification it is very unlikely to change.
No matter whether you're using the 32-bit version or 64-bit version of the CLR, in C# an int will always mean System.Int32 and long will always mean System.Int64.
The following will always be true in C#:
sbyte signed 8 bits, 1 byte
byte unsigned 8 bits, 1 byte
short signed 16 bits, 2 bytes
ushort unsigned 16 bits, 2 bytes
int signed 32 bits, 4 bytes
uint unsigned 32 bits, 4 bytes
long signed 64 bits, 8 bytes
ulong unsigned 64 bits, 8 bytes
An integer literal is just a sequence of digits (eg 314159) without any of these explicit types. C# assigns it the first type in the sequence (int, uint, long, ulong) in which it fits. This seems to have been slightly muddled in at least one of the responses above.
Weirdly the unary minus operator (minus sign) showing up before a string of digits does not reduce the choice to (int, long). The literal is always positive; the minus sign really is an operator. So presumably -314159 is exactly the same thing as -((int)314159). Except apparently there's a special case to get -2147483648 straight into an int; otherwise it'd be -((uint)2147483648). Which I presume does something unpleasant.
Somehow it seems safe to predict that C# (and friends) will never bother with "squishy name" types for >=128 bit integers. We'll get nice support for arbitrarily large integers and super-precise support for UInt128, UInt256, etc. as soon as processors support doing math that wide, and hardly ever use any of it. 64-bit address spaces are really big. If they're ever too small it'll be for some esoteric reason like ASLR or a more efficient MapReduce or something.
Yes, as Jon said, and unlike the 'C/C++ world', Java and C# aren't dependent on the system they're running on. They have strictly defined lengths for byte/short/int/long and single/double precision floats, equal on every system.
int without suffix can be either 32bit or 64bit, it depends on the value it represents.
as defined in MSDN:
When an integer literal has no suffix, its type is the first of these types in which its value can be represented: int, uint, long, ulong.
Here is the address:
https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx
In my C# source code I may have declared integers as:
int i = 5;
or
Int32 i = 5;
In the currently prevalent 32-bit world they are equivalent. However, as we move into a 64-bit world, am I correct in saying that the following will become the same?
int i = 5;
Int64 i = 5;
No. The C# specification rigidly defines that int is an alias for System.Int32 with exactly 32 bits. Changing this would be a major breaking change.
The int keyword in C# is defined as an alias for the System.Int32 type and this is (judging by the name) meant to be a 32-bit integer. To the specification:
CLI specification section 8.2.2 (Built-in value and reference types) has a table with the following:
System.Int32 - Signed 32-bit integer
C# specification section 8.2.1 (Predefined types) has a similar table:
int - 32-bit signed integral type
This guarantees that both System.Int32 in CLR and int in C# will always be 32-bit.
Will sizeof(testInt) ever be 8?
No, sizeof(testInt) is an error. testInt is a local variable. The sizeof operator requires a type as its argument. This will never be 8 because it will always be an error.
VS2010 compiles a c# managed integer as 4 bytes, even on a 64 bit machine.
Correct. I note that section 18.5.8 of the C# specification defines sizeof(int) as being the compile-time constant 4. That is, when you say sizeof(int) the compiler simply replaces that with 4; it is just as if you'd said "4" in the source code.
Does anyone know if/when the time will come that a standard "int" in C# will be 64 bits?
Never. Section 4.1.4 of the C# specification states that "int" is a synonym for "System.Int32".
If what you want is a "pointer-sized integer" then use IntPtr. An IntPtr changes its size on different architectures.
int is always synonymous with Int32 on all platforms.
It's very unlikely that Microsoft will change that in the future, as it would break lots of existing code that assumes int is 32-bits.
I think what you may be confused by is that int is an alias for Int32 so it will always be 4 bytes, but IntPtr is suppose to match the word size of the CPU architecture so it will be 4 bytes on a 32-bit system and 8 bytes on a 64-bit system.
According to the C# specification ECMA-334, section "11.1.4 Simple Types", the reserved word int will be aliased to System.Int32. Since this is in the specification it is very unlikely to change.
No matter whether you're using the 32-bit version or 64-bit version of the CLR, in C# an int will always mean System.Int32 and long will always mean System.Int64.
The following will always be true in C#:
sbyte signed 8 bits, 1 byte
byte unsigned 8 bits, 1 byte
short signed 16 bits, 2 bytes
ushort unsigned 16 bits, 2 bytes
int signed 32 bits, 4 bytes
uint unsigned 32 bits, 4 bytes
long signed 64 bits, 8 bytes
ulong unsigned 64 bits, 8 bytes
An integer literal is just a sequence of digits (eg 314159) without any of these explicit types. C# assigns it the first type in the sequence (int, uint, long, ulong) in which it fits. This seems to have been slightly muddled in at least one of the responses above.
Weirdly the unary minus operator (minus sign) showing up before a string of digits does not reduce the choice to (int, long). The literal is always positive; the minus sign really is an operator. So presumably -314159 is exactly the same thing as -((int)314159). Except apparently there's a special case to get -2147483648 straight into an int; otherwise it'd be -((uint)2147483648). Which I presume does something unpleasant.
Somehow it seems safe to predict that C# (and friends) will never bother with "squishy name" types for >=128 bit integers. We'll get nice support for arbitrarily large integers and super-precise support for UInt128, UInt256, etc. as soon as processors support doing math that wide, and hardly ever use any of it. 64-bit address spaces are really big. If they're ever too small it'll be for some esoteric reason like ASLR or a more efficient MapReduce or something.
Yes, as Jon said, and unlike the 'C/C++ world', Java and C# aren't dependent on the system they're running on. They have strictly defined lengths for byte/short/int/long and single/double precision floats, equal on every system.
int without suffix can be either 32bit or 64bit, it depends on the value it represents.
as defined in MSDN:
When an integer literal has no suffix, its type is the first of these types in which its value can be represented: int, uint, long, ulong.
Here is the address:
https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx