I have an Informix stored procedure which takes an int and a "smallint" as parameters. I'm trying to call this SP from a .net4 Visual Basic program.
As far as I know, "smallint" is a byte. Unfortunately, when loading up the IfxCommand.Parameters collection with an Integer and a Byte, I get an ArgumentException thrown of {"The parameter data type of Byte is invalid."} with the following stack trace:
at IBM.Data.Informix.TypeMap.FromObjectType(Type dataType, Int32 length)
at IBM.Data.Informix.TypeMap.FromObjectType(Type dataType)
at IBM.Data.Informix.IfxParameter.GetTypeMap()
at IBM.Data.Informix.IfxParameter.GetOutputValue(IntPtr stmt, CNativeBuffer valueBuffer, CNativeBuffer lenIndBuffer)
at IBM.Data.Informix.IfxDataReader.Dispose(Boolean disposing)
at IBM.Data.Informix.IfxDataReader.System.IDisposable.Dispose()
at IBM.Data.Informix.IfxCommand.ExecuteReaderObject(CommandBehavior behavior, String method)
at IBM.Data.Informix.IfxCommand.ExecuteReader(CommandBehavior behavior)
at IBM.Data.Informix.IfxCommand.ExecuteReader()
Presumably I need to cast the Byte I have to a smallint, somehow, but google isn't giving me any relevant answers, just at the moment.
I have tried using:
cmd.Parameters.Add(New IfxParameter("myVal", IBM.Data.Informix.IfxType.SmallInt)).Value = myByte
but I still get the same ArgumentException when executing the reader.
Can someone tell me what I'm doing wrong?
An Informix SmallInt is a 16 bit signed integer, byte is an 8 bit unsigned integer. A better equivalent would be Int16 or Short which is a 16 bit signed integer, just like SmallInt. I suspect that will work.
Informix has no analogue for an unsigned 8 bit integer like the .Net Byte or the TSQL TinyInt.
Int16 should work since it has the same range than SmallInt (-32,767 to 32,767)
Informix has 4 types that are related: BYTE and TEXT (since 1990), BLOB and CLOB (since 1996). Collectively, they are all large objects. A BYTE type is absolutely NOT a small integer type.
You may be able to use BYTE in a language that thinks it is a small integer if the language or driver fixes up the types.
But the native BYTE type is a large object. It requires a 56-byte descriptor in the main row of data, and then uses other storage (possibly IN TABLE, possibly in a blobspace) for the actual data storage.
Related
I have been using an earlier version of webrtc code. Today, I fetched the latest code and it broke my build:-(. It appears that WebRtcNs_Process now takes a "float" type buffer instead of "int16" type buffer. There may be a good reason to do so. However, this also seems to have broken the chain of operations.
Typically, you first call WebRtcNs_Process and feed the output of this method to WebRtcAecm_Process. In the latest version, the output of WebRtcNs_Process is a float type buffer but the input to WebRtcAecm_Process is a int16 buffer. Seems like now I have to write extra code to convert float buffer to int16 buffer.
Also, on most platforms, the output from the mic is int16 type buffer. There is additional code I have to write to convert this int16 value to float so that I can pass it to WebRtcNs_Process.
I am wondering if I missed something. Regards.
I'm parsing xml via libxml2 library. After updating Xcode to 5.1, I got warning that last parameter - length - is implicitly converted to int, while it's unsigned long.
Here's function declaration:
XMLPUBFUN xmlNodePtr XMLCALL
xmlNewCDataBlock(xmlDocPtr doc,
const xmlChar *content,
int len);
Is there any similar function that takes unsigned long values, because I don't know how big my data can be, and I want to process it safely.
There's no such function. libxml2's string manipulation functions use ints for string lengths and offsets, so text nodes longer than INT_MAX are not supported.
Related:
Is it safe to assume an int will
always be 32 bits in C#?
The linked question asks whether it is "safe to assume that an int will always be 32 bits in C#". The accepted answer states that "the C# specification rigidly defines that int is an alias for System.Int32 with exactly 32 bits".
My question is this: does this hold true for VB.Net's Integer? Is it safe to assume that Integer will always be an alias for int32?
Yes.
The Integer type will never change.
The spec (7.3 Primitive Types) says:
The integral value types Byte (1-byte unsigned integer), Short (2-byte signed integer), Integer (4-byte signed integer), and Long (8-byte signed integer). These types map to System.Byte, System.Int16, System.Int32, and System.Int64, respectively. The default value of an integral type is equivalent to the literal 0.
VB.Net doesn't have an "int", it has an "Integer" type. The Integer type is an alias for System.Int32. So no, this will not change.
I need to read signed and unsigned 8 bit, 16 bit and 32 bit values from a file stream which may be little-endian or big-endian (it happens to be a tiff file which carries the byte order indicator at the start).
I initially started by writing my own functions to read the values and was able to do so for unsigned values. e.g.
Public Function ReadUInt32() As UInt32
Dim b(4) As Byte
input.Read(b, 0, 4)
Dim out As UInt32 = CUInt(If(IsBigEndian, b(0), b(3))) << 24
out += CUInt(If(IsBigEndian, b(1), b(2))) << 16
out += CUInt(If(IsBigEndian, b(2), b(1))) << 8
out += CUInt(If(IsBigEndian, b(3), b(0)))
Return out
End Function
But then I started looking at signed values and my brain broke.
As an alternative, I found the IO.BinaryReader which will let me read signed values directly but doesn't seem to have any way to indicate that the data is big-endian or little-endian.
Is there a nice way of handling this? Failing that, can someone tell me how to convert multiple bytes into signed values (in both byte orders)?
It's not ideal, but you can use the various overloads of the HostToNetworkOrder and NetworkToHostOrder methods from the System.Net.IPAddress class to do signed-integer endian conversion.
Have you taken a look at the BitConverter Class?
http://msdn.microsoft.com/en-US/library/system.bitconverter_members(v=VS.80).aspx
Some byte shuffling and a call to ToUInt32 should get what you want.
I need to a variable which holds a 24 bits value, what should I use ?
Also, do you know a list of all available types in Objc?
Thanks a lot.
You could use an int. It will hold 24 bits. (32, actually)
Objective-C has exactly the same types as plain C. All object references and the id type are technically pointers.
The size of integer datatypes (char … long long) is not defined but their relation and minimum size is.
The smallest integer data type guaranteed to hold 24bit is long int which must be at least 32bit.
int may be 16bit on some systems.
3 chars will be at least 24bit since a char must have 8bit or more.
An array of 3 unsigned chars will be 24 bits (on most systems).