Here is my solidity code.
contract TestLog {
bytes constant internal EMPTY_BYTES = "";
event Logempty(bytes data);
function Log() public {
emit Logempty(EMPTY_BYTES);
}
}
so everythime I execute Log()，it print 0x20 in event log, why not 0x00 ?
I deployed it on Ropsten network. Here is the link:
https://ropsten.etherscan.io/address/0xb0723e0943b7b10c985365df6aef983bc6eeb6d6#events
Because the ASCII code of a blank space is actually 0x20. You can read more about those here.
To clarify:
What you are using there, "", is actually the empty string and in most programming languages is different from null. So being a string of length zero, as it's also stated here, there is also memory required to store it.
Hope that helps :)
I'm learning Solidity Assembly and I'm confused about something. I'm looking at this library called Seriality. Specifically, this function: https://github.com/pouladzade/Seriality/blob/master/src/TypesToBytes.sol#L21
function bytes32ToBytes(uint _offst, bytes32 _input, bytes memory _output) internal pure {
assembly {
mstore(add(_output, _offst), _input)
mstore(add(add(_output, _offst),32), add(_input,32))
}
}
That function bytes32ToBytes takes a bytes32 variable and stores it in a dynamically sized bytes array, starting at the offset passed in.
The thing that confuses me is that it uses the mstore function twice. But the mstore function stores a word, which is 32 bytes, right? So why is it called twice, given that the input is 32 bytes? Wouldn't calling it twice store 2 words, which is 64 bytes?
Thanks!
Solidity arrays are stored by writing out the size of the array to the first storage slot then writing out the data to the subsequent slots.
Knowing that mstore has the following parameters: mstore(START_LOCATION, ITEM_TO_STORE), the first mstore statement is written as follows:
mstore(add(_output, _offst), _input)
Since the first slot of the array points to the size of the array, this statement is setting the size of _output. You should be able to get the same result by replacing it with mstore(add(_output, _offst), 32) (since the size is of _input is static).
The second statement (mstore(add(add(_output, _offst),32), add(_input,32))) is the one that writes the data itself. Here, we are shifting the position of both pointers by 32 bytes (as the first 32 bytes for both arrays are pointing to the size) and storing the value of _input to where the data is stored for _output.
Chances are, _output will already be initialized before calling this method (so the length will already be set), so it will usually be unnecessary. But, it doesn't hurt. Note that a similar implementation making this assumption would look like this:
function test() public pure returns (bytes) {
bytes32 i = "some message";
bytes memory o = new bytes(32); // Initializing this way sets the length to the location "o" points to. This replaces mstore(add(_output, _offst), _input).
bytes32ToBytes(0, i, o);
return o;
}
function bytes32ToBytes(uint _offst, bytes32 _input, bytes memory _output) internal pure {
assembly {
mstore(add(add(_output, _offst),32), add(_input,32))
}
}
Not sure about the intention of the function bytes32ToBytes
If it is turning a bytes32 into a bytes, I think the right implementation should be
pragma solidity ^0.7.0;
contract DecodeEncode {
function test() public pure returns (bytes memory) {
bytes32 i = "some message";
bytes memory o = new bytes(32); // Initializing this way sets the length to the location "o" points to. This replaces mstore(add(_output, _offst), _input).
bytes32ToBytes(0, i, o);
return o;
}
function bytes32ToBytes(uint _offst, bytes32 _input, bytes memory _output) internal pure {
assembly {
mstore(add(_output, _offst), 32) //lineA
mstore(add(add(_output, _offst), 32), _input) //lineB
}
}
}
lineA sets the length of the bytes as 32 bytes
lineB sets the content of the first slot of the bytes as _input
I have a string of bits(binary number) and I want to write it to a ByteArray(or maybe later in a file) is it correct to do it this way or should I first convert the binary string to hex ?
var bits:String="11001110";//8 bits a byte
var CompressedBytes = new ByteArray();
CompressedBytes.writeByte((int)(bits));
and if so please provide an example.
Your code is almost correct. Use the global parseInt(...) function that reads a given String and converts it into a Number. There's an optional second argument that allows you to specify a base of the number you are willing to parse. The most common values are 2 (for binary notation), 8 (for octal numbers), 10 (for decimal numbers, which is default) or 16 (for hexadecimal notation).
var bits:String = "11001110"; //8 bits a byte
var aByte:int = parseInt(bits, 2);
var CompressedBytes = new ByteArray;
CompressedBytes.writeByte(aByte);
P.S. You can convert a Number (also int and uint) to a String notation with a given base via toString(...) method.
I would like to redirect rows hat could not be loaded into a table to an error file.
I see that the red exception path has 3 Input columns coming in, the "Flat File Source Error Output Column" contains the original data in the file.
The problem is that when I open the file, there is an extra Carriage Return\Line Feed character after every row. I'd like to be able to manually fix the errors and reprocess them without having to delete all of the added CRLF chars. So I added a Script Component to shave of the characters being added.
public override void Input0_ProcessInputRow(Input0Buffer Row)
{
string buffer = GetString(Row.FlatFileSourceErrorOutputColumn.GetBlobData(0, (int)(Row.FlatFileSourceErrorOutputColumn.Length)));
System.Windows.Forms.MessageBox.Show(buffer);
byte[] ThisBytes = GetBytes("Test");
Row.FlatFileSourceErrorOutputColumn.ResetBlobData();
Row.FlatFileSourceErrorOutputColumn.AddBlobData(ThisBytes);
}
static string GetString(byte[] bytes)
{
char[] chars = new char[bytes.Length / sizeof(char)];
System.Buffer.BlockCopy(bytes, 0, chars, 0, bytes.Length);
return new string(chars);
}
static byte[] GetBytes(string str)
{
byte[] bytes = new byte[str.Length * sizeof(char)];
System.Buffer.BlockCopy(str.ToCharArray(), 0, bytes, 0, bytes.Length);
return bytes;
}
But my debug message box shows non displayable characters that appear as blocks.
When I try to force a literal "TEST" to the output file as a test to see if I could control what goes into the file, I get NULL (ASCII 0) characters after every letter.
Why is SSIS adding a CRLF when I just simply redirect the Output column to the file w/o using a Scripting block component to attempt to modify the data written? How can I get rid of the CRLF? Why am I unable to read the byte array in the data column and display it as a string? Why is the "TEST" literal having NULLS between every letter? Is my ByteArray conversion functions incorrect?
Got it.
public override void Input0_ProcessInputRow(Input0Buffer Row)
{
string buffer = GetString(Row.FlatFileSourceErrorOutputColumn.GetBlobData(0, (int)(Row.FlatFileSourceErrorOutputColumn.Length - 2)));
System.Windows.Forms.MessageBox.Show(buffer);
byte[] ThisBytes = GetBytes(buffer);
Row.FlatFileSourceErrorOutputColumn.ResetBlobData();
Row.FlatFileSourceErrorOutputColumn.AddBlobData(ThisBytes);
}
static string GetString(byte[] bytes)
{
System.Text.Encoding enc = System.Text.Encoding.ASCII;
return enc.GetString(bytes);
}
static byte[] GetBytes(string str)
{
System.Text.Encoding enc = System.Text.Encoding.ASCII;
return enc.GetBytes(str);
}
I would still like to know why SSIS is adding the CRLF!
how do i convert this C++ code to AS3
void myFunc(BYTE type)
{
//send type to the network server..
}
There is no such type as BYTE in ActionScript 3 but you can use 'int' instead.
It will looks something like this:
var socket:flash.net.Socket;
//...
function myFunc( type:int ):void {
socket.writeByte( type );
}
As it said in Socket docs: "The low 8 bits of the value are used; the high 24 bits are ignored." So only 8 bits will be written to socket just like it is expected with BYTE in C++.