I have a space delimited set of hex values and want to find /[0-9a-f]\{2\} unless the value is 00. For example, if the buffer is
00 00 00 00 18 00 00 00
the pattern should match the 18 but not the white space or the 00.
This can be done with the following regular expression:
\x\{2}\(00\)\#<!
Explanation:
\x: hex digit: [0-9A-Fa-f]
\{2}: matches two of the preceding atom
\(00\): an atom containing 00
\#<! nothing, requires NO match behind
For more information, see:
:help pattern.txt
Related
I got 8 bytes Hex values in a cell as below which is in little endian format
00 00 08 04 22 00 40 00
With text split I could get individual hex values in an array.
= TEXTSPLIT(A1, , " ")
00
00
08
04
22
00
40
00
Is there an excel formula that I can use to grab the values in reverse order from an array to do below?
00
40
00
22
04
08
00
00
I don't want to use LEFT or MID or RIGHT extractors as I want to create generic formula that works on all data types.
For this very specific case you could use =TRIM(CONCAT(MID(" "&A1,SEQUENCE(8,,22,-3),3))) but to be more generic, try:
Formula in A2:
=TEXTJOIN(" ",,SORTBY(TEXTSPLIT(A1,," "),ROW(1:8),-1))
I suppose you can make this even more generic for any string you split on space:
=LET(r,TEXTSPLIT(A1,," "),TEXTJOIN(" ",,SORTBY(r,SEQUENCE(ROWS(r)),-1)))
Note this is almost an exact copy of this question where you could also use the technique shown by #ScottCraner using INDEX().
=MID(SUBSTITUTE(A1, " ", ""), SEQUENCE(1, LEN(SUBSTITUTE(A1, " ", ""))/2, LEN(SUBSTITUTE(A1, " ", ""))-1, -2), 2)
I'm new to Rust and I've been trying to understand how it stores enums in memory.
I already know Rust implements tagged unions to represent enums.
From what I've understood, this is what I should see in memory:
An incremental tag (1 byte)
As many bytes as the largest field
Some padding bytes (if needed) for alignment purposes
Consider the following piece of code:
enum MyEnum {
A(u8, u8),
B(u16),
C(bool),
D
}
fn main() {
let v = vec![
MyEnum::D,
MyEnum::A(3, 2),
MyEnum::B(10),
MyEnum::C(true),
];
}
This is what I see inside actual memory:
03 00 00 00
00 03 02 FF
01 F0 0A 00
02 01 00 00
My explanation:
First row => TAG = 03 && VALUE = 3 null bytes
Second row => TAG = 00 && VALUE = (03, 02) && PADDING = 1 byte (I guess padding doesn't necessarily have to be a NULL byte)
Third row => TAG = 01 && PADDING = 1 byte && VALUE = 0A 00 (little-endian memory)
Fourth row => TAG = 02 && VALUE = 01 (true) && PADDING = 2 bytes
What I don't understand:
I don't quite understand the third row's layout: why does it have a padding byte right after the tag? Shouldn't it be at the end?
It becomes even worse if I add a 32-bit field to the enum.
Second example with 32-bit field:
enum MyEnum {
A(u8, u8),
B(u16),
C(bool),
D,
E(u32)
}
fn main() {
let v = vec![
MyEnum::D,
MyEnum::A(3, 2),
MyEnum::B(10),
MyEnum::C(true),
MyEnum::E(12949)
];
}
This is what I see inside actual memory:
03 00 00 00 00 00 00 00
00 03 02 00 00 00 00 00
01 FF 0A 00 FF FF FF FF
02 01 7F FF FF 7F 00 00
04 00 00 00 95 32 00 00
What I don't understand:
Why doesn't the 32-bit value (0x3295 = 12949) start from the end like the 16-bit value in the previous example? Why is there padding right after the tag (1 byte) and right after the number (2 bytes)?
In your last example, the value 12949 actually stands in the four last bytes: 95 32 00 00 in little endian (0x95 + 0x32 * 256)
This a 4-bytes word, then it is aligned to a multiple of 4 address.
The value 10 is stored in a 2-bytes word, then its value is aligned to a multiple of 2 address.
If it was just after the tag, then the alignment of this field would not be 2.
The whole enum is probably aligned to a large power of 2, in order to be certain of the alignment of the various fields it contains, just by adding the required padding.
That's why the enum grows from 4 bytes to 8 bytes when you add the last field.
If the whole enum is already aligned to a multiple of 4, and the first byte is used by the discriminant, then we need to skip 3 bytes in order to find the next multiple of 4.
I'm trying to convert and write string data into the file as bytes.
I have already tried something to, but instead of seeing 00 inside hexdump, im seeing 0x30 inside file which is hexadecimal value for character 0.
Here is what I wrote:
local data = "000000010000000100000004000000080000000100000000"
for i=1,#data,2 do
file:write(tonumber(data:sub(i,i+1)))
end
io.close(file)
When I do hexdump of the file I'm getting this:
0000000 30 30 30 31 30 30 30 31 30 30 30 34 30 30 30 38
0000010 30 30 30 31 30 30 30 30
0000018
Expected is:
0000000 00 00 00 01 00 00 00 01 00 00 00 04 00 00 00 08
0000010 00 00 00 01 00 00 00 00
0000018
You want to use string.char in one way:
local data = "000000010000000100000004000000080000000100000000"
for i=1,#data,2 do
file:write(string.char(tonumber(data:sub(i,i+1), 16)))
end
io.close(file)
or another:
local data = string.char(0,0,0,1,0,0,0,1,0,0,0,4,0,0,0,8,0,0,0,1,0,0,0,0)
file:write(data)
io.close(file)
Note that strings in Lua may contain any bytes you want including null bytes. See Values and Types.
Hint: Use string.char to convert numbers to bytes:
file:write(string.char(tonumber(data:sub(i,i+1))))
If the strings contains hexadecimal, use tonumber(...,16).
I'm attempting to copy/paste ASCII characters from a Hex editor into a Sublime Text 3 Plain Text document, although NUL characters do not show/display and the string is truncated:
Hexadecimal:
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 00 66 6F
6F 62 61 72 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
ASCII:
Hello, World!�foobar�������������������������
Sublime Text: Truncates copied string and does not show NUL characters
TextMate: Shows NUL via "Show Invisibles"
I've tried the suggestion mentioned here by adding "draw_white_space": "all" to my preferences — still no luck! Is this possible with Sublime Text 3?
You're not alone in having this problem - others have posted bug reports about this behaviour: https://github.com/SublimeTextIssues/Core/issues/393
However it's not consistent:
Behaviour seems dependent on the file and where the NUL chars exist;
Similar issue here, with the console: https://github.com/SublimeTextIssues/Core/issues/1939
I have a file which contains several paragraphs as below:
[730480.910190] [MACSTATUSIND] ACTIND_ParseMACSTATUS:
[730480.910205] fe 0a 39 01 0a 00 51 e7 ba 9d c7 0d 00 00 00 00 ..9...Q....
[730480.910220] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...........
[730480.910233] 00 00 00 00 00 00 00 00 00 00 xx xx xx xx xx xx .....:bC.B.
[730480.910247] xx xx yy yy yy yy yy yy zz zz 64 34 e8 ff 00 00 ......d4...
from above data, for each paragraph i want to make three columns:
xxxxxxxx | yyyyyy | zzzz
| |
| |
and then store those rows in a different/new file.
I tried using grep and cut, but it's too lengthy and don't have enough idea about sed & awk commands.
How to solve above scenario using sed and awk commands!!
Consider this a 'code golf' solution, at least I had some fun with it;)
<file sed -n '/MACSTAT/ {n;n;n;p;n;p}' |
cut -c 17-63 |
paste -d' ' - - |
cut -c 31-78 |
sed -e 's/ /|/8' -e 's/ /|/13' |
tr -d ' '
I suggest to remove the parts of the pipe from the end to figure out what exactly the commands do to the input. In general the first sed finds the header, skips three lines, prints the next two. Then cut keeps only the hexprint. Then paste joins each two consecutive lines into one. Then cut takes out only the required bytes. Then sed substitutes particular spaces with column separators. Then tr removes the remaining spaces.
You can try this sed (GNU sed) 4.4
sed -nE '
/\[MACSTATUSIND] ACTIND_ParseMACSTATUS:/N;N;N;N
# get 5 lines if the first contain MACSTAT...
s/.*\n[^ ]* //
# keep only the last line after the first space
s/ //g
# remove all spaces
s/(.{4})(.{12})(.{4}).*/\1|\2|\3/p
# keep only the 20 char you want and
# format them in 3 columns with delimiter |
' infile