I read a 17 byte hex string from command line "13:22:45:33:99:cd" and want to convert it into binary value of length 6 bytes.
For this, I read a 17 byte hex string from command line "13:22:45:33:99:cd" and converted it into binary digits as 0001 0011 0010 0010 0100 0101 0011 0011 1001 1001 1100 1101. However, since I am using a char array, it is of length 48 bytes. I want the resulting binary to be of length 6 bytes i.e, I want 0001 0011 0010 0010 0100 0101 0011 0011 1001 1001 1100 1101 to be of 6 bytes (48 bits) and not 48 bytes. Please suggest how to accomplish this.
Split the string on the ':' character, and each substring is now a string you can pass to e.g. strtoul and then put in a unsigned char array of size 6.
#include <stdio.h>
const char *input = "13:22:45:33:99:cd";
int output[6];
unsigned char result[6];
if (6 == sscanf(input, "%02x:%02x:%02x:%02x:%02x:%02x",
&output[0], &output[1], &output[2],
&output[3], &output[4], &output[5])) {
for (int i = 0; i < 6; i++)
result[i] = output[i];
} else {
whine("something's wrong with the input!");
}
You pack them together. Like high nibble with low nibble: (hi<<4)|lo (assuming both are 4-bits).
Although you may prefer to convert them byte by byte, not digit by digit in the first place.
Related
This question already has answers here:
Best practices for circular shift (rotate) operations in C++
(16 answers)
Closed 2 years ago.
I'm trying to rotate hexadecimal numbers in C. The problem I have is that, with each loop. more zeros occur in the number.
Here is my code:
int main (void) {
int hex = 0x1234ABCD;
for(int i=0; i<12;i++,hex <<=4){
printf("0x%04x %d ",hex,hex );
pattern(hex);
}
return 0;
}
I saw some other code on this site which added & 0x0F to the shift, but it is not working for me.
Here are my results with the compiler
0x1234abcd 305441741 0001 0010 0011 0100 1010 1011 1100 1101
0x234abcd0 592100560 0010 0011 0100 1010 1011 1100 1101 0000
0x34abcd00 883674368 0011 0100 1010 1011 1100 1101 0000 0000
0x4abcd000 1253888000 0100 1010 1011 1100 1101 0000 0000 0000
0xabcd0000 -1412628480 1010 1011 1100 1101 0000 0000 0000 0000
Thank you for your help.
There is no operator that does a rotation for you. You need to combine 2 shift operations. Also you should use unsigned values when doing bitshift operations.
int main (void) {
unsigned int hex = 0x1234ABCD;
for(int i=0; i<12;i++) {
printf("0x%04x %d ",hex,hex );
pattern(hex);
unsigned int upper = hex >> (sizeof(hex)*CHAR_BIT - 4);
hex <<= 4;
hex |= upper & 0x0F;
}
return 0;
}
When you use the left-shift (<<) operator on a number, shifting by n bits, then the most significant n bits of that number are lost, and the least significant n bits are filled with zeros (as you have noticed).
So, in order to perform a bitwise rotation, you need to first 'save' those top 4 bits, then put them back (using the | operator after shifting them down to the bottom).
So, assuming a 32-bit int size, something like this:
#include <stdio.h>
int main(void)
{
int hex = 0x1234ABCD;
for (int i = 0; i < 12; i++) {
printf("0x%04x %d ", hex, hex);
pattern(hex);
int save = (hex >> 28) & 0x0F; // Save TOP four bits of "hex" in BOTTOM 4 of "save"
hex <<= 4; // Now shift the bits to the left ...
hex |= save; // ... then put those saved bits in!
}
return 0;
}
Note: We mask the save value with 0x0F after the shift to make sure that all other bits are 0; if we don't do this then, with negative numbers, we are likely to get those other bits filled with 1s.
I have a 64-bit unsigned integer. Which contains 0s in the first two MSB bytes. How can I mask out that first two MSB bytes?
uint64 value;
value = 0000 0000 0000 0000 0000 1101 1111 1010 1110 1111 1111 1111 0101
0101 1101 1101;
uint48 answer;
answer = 0000 1101 1111 1010 1110 1111 1111 1111 0101
0101 1101 1101;
In the above example, the value is a 64-bit number. I want the answer to contain all the bits other than first 2 bytes. So, that I can pack the answer in a byte array of size 6. How can I achieve this in C?
Mask it with 48 1-bits: 0xffffffffffff
uint64_t value = <something>;
uint48_t answer = src & 0xffffffffffff;
But if you know the 2 MSB are zeroes, you don't need to do any masking, just assign the variables:
uint48_t answer = value;
To store them in a byte array, shift by the appropriate number of bytes and mask with 0xff to get a single byte.
uint8_t bytes[6];
for (int i = 0; i < 6; i++) {
bytes[i] = (value >> (40 - 8 * i)) & 0xff;
}
You can use either the original 64-bit value or the 48-bit value, this works for any size at least 6 bytes.
Make a union with your uint64_t value and an array of Bytes.
typefef union
{
uint8_t ByteArray[8];
uint64_t Value;
}Array64T;
Array64T CompleteValue;
CompleteValue.Value = ...
void *copt6lsb(uint64_t val, void *buff)
{
union{
uint8_t d8[2];
uint16_t d16;
}u16 = {.d8[0] = 0xff};
char *pos = &val;
pos = pos + 2 * (u16.d16 == 0xff00);
memcpy(buff, pos, 6);
return buff;
}
Good thing is that most compilers then the optimization is on will optimize out the union and will replace the comparison with assignment.
https://godbolt.org/z/JKXDC2
and platforms which allow unaligned access will optimize the memcpy as well
https://godbolt.org/z/c3_ypL
I'm having trouble understanding why c equals -61 on the following program:
main() {
unsigned int a = 60; // 60 = 0011 1100
unsigned int b = 13; // 13 = 0000 1101
int c = 0;
c = ~a; //-61 = 1100 0011
printf("Line 4 - Value of c is %d\n", c );
}
I do understand how the NOT operator works on 0011 1100 (the solution being 1100 0011). But I'm not sure why the decimal number is increased by 1. Is this some sort of type conversion from unsigned int (from a) into signed int (from c) ?
Conversion from a positive to a negative number in twos complement (the standard signed format) constitutes a bitwise inversion, and adding one.
Note that for simplicity I am using a single signed byte.
So if 60 = 0011 1100
Then c = 1100 0011 + 1
= 1100 0100
And for a signed byte, the most significant bit is negative,
so
c = -128 + 64 + 4 = -60
You need to add 1 to account for the fact that the most significant bit is -128, while the largest positive number is 0111 1111 = 127. All negative numbers have a 1 for -128 which needs to be offset.
This is easy to see when you look at converting 0 to -0. Invert 00000000 and you get 11111111 and adding one gets you back to 00000000. Do the same with 1 to -1 and you get 11111111 - the largest possible negative number.
I've been given the following assignment in a C-course:
I've implemented the assignment to decode the 8 byte long long int 131809282883593 as follows:
#include <stdio.h>
#include <string.h>
struct Message {
unsigned int hour : 5;
unsigned int minutes : 6;
unsigned int seconds : 6;
unsigned int day : 5;
unsigned int month : 4;
unsigned int year : 12;
unsigned long long int code : 26;
}; // 64 bit in total
union Msgdecode {
long long int datablob;
struct Message elems;
};
int main(void) {
long long int datablob = 131809282883593;
union Msgdecode m;
m.datablob = datablob;
printf("%d:%d:%d %d.%d.%d code:%lu\n", m.elems.hour, m.elems.minutes,
m.elems.seconds, m.elems.day, m.elems.month, m.elems.year,(long unsigned int) m.elems.code);
union Msgdecode m2;
m2.elems.hour = 9;
m2.elems.minutes = 0;
m2.elems.seconds = 0;
m2.elems.day = 30;
m2.elems.month = 5;
m2.elems.year = 2017;
m2.elems.code = 4195376;
printf("m2.datablob: should: 131809282883593 is: %lld\n", m2.datablob); //WHY does m2.datablob != m.datablob?!
printf("m.datablob: should: 131809282883593 is: %lld\n", m.datablob);
printf("%d:%d:%d %d.%d.%d code:%lu\n", m2.elems.hour, m2.elems.minutes,
m2.elems.seconds, m2.elems.day, m2.elems.month, m2.elems.year, (long unsigned int) m2.elems.code);
}
TRY IT ONLINE.
..what gives me a hard time is the output. The decoding/encoding works nicely so far. 9:0:0 30.5.2017 and code 4195376 is expected, but the difference in the 'datablob' really isn't - and i can't figure out why/where it stems from:
9:0:0 30.5.2017 code:4195376
m2.datablob: should: 131809282883593 is: 131810088189961
m.datablob: should: 131809282883593 is: 131809282883593
9:0:0 30.5.2017 code:4195376
As you can see the datablob is close to the original - but not the original. I've consulted a coworker whos fluent in C about this - but we couldn't figure out the reason for this behaviour.
Q: Why do the blobs differ from each other?
Bonus-Q: When manipulating the union Msgdecode to include another field, a strange thing happens:
union Msgdecode {
long long int datablob;
struct Message elems;
char bytes[8]; // added this
};
Outcome:
9:0:0 30.5.2017 code:0
m2.datablob: should: 131809282883593 is: 8662973939721
m.datablob: should: 131809282883593 is: 131809282883593
9:0:0 30.5.2017 code:4195376
PS: reading on SO about bitfields+union questions gave me the impression that they are rather unreliable. Can this be generally said?
The layout of bitfields within a struct and any padding that may exist between them is implementation defined.
From section 6.7.2.1 of the C standard:
11 An implementation may allocate any addressable storage unit large enough to hold a bit- field. If enough space remains, a bit-field
that immediately follows another bit-field in a structure shall be
packed into adjacent bits of the same unit. If insufficient space
remains, whether a bit-field that does not fit is put into
the next unit or overlaps adjacent units is
implementation-defined. The order of allocation of bit-fields within
a unit (high-order to low-order or low-order to high-order) is
implementation-defined. The alignment of the addressable storage
unit is unspecified.
This means that you can't rely on the layout in a standard-compliant manner.
That being said, lets take a look at how the bits are being laid out in this particular case. To reiterate, everything from here down is in the realm of implementation defined behavior. We'll start with the second case where m2.datablob is 8662973939721 as that is easier to explain.
First let's look at the bit representation of the values you assign to m2:
- hour: 9: 0 1001 (0x09)
- minutes: 0: 00 0000 (0x00)
- seconds: 0: 00 0000 (0x00)
- day: 30: 11 1110 (0x3E)
- month: 5: 0101 (0x05)
- year: 2017: 0111 1110 0001 (0x7e1)
- code: 4195376: 00 0100 0000 0000 0100 0011 0000 (0x0400430)
Now let's look at the blob values, first m which assigns to blobvalue then m2 which assigns to each field individually with the above values:
131809282883593 0x77E13D7C0009 0111 0111 1110 0001
0011 1101 0111 1100 0000 0000 0000 1001
8662973939721 0x07E1017C0009 0000 0111 1110 0001
0000 0001 0111 1100 0000 0000 0000 1001
If we start by looking at the values from the right going left, we can see the value 9, so there's our first 5 bits. Next is two sets of 6 zero bits for the next two fields. After that, we see the bit patterns for 30, then 5.
A little further up we see the bit pattern for the value 2017, but there are 6 bits set to zero between this value and the prior ones. So it looks like the layout is as follows:
year ??? month day sec min hour
------------ ----- --- ---- ------ ----- -----
| | | || || || || | |
0000 0111 1110 0001 0000 0001 0111 1100 0000 0000 0000 1001
So there's some padding between the year and month fields. Comparing the m and m2 representations, the differences are in the 6 bits of padding between month and year as well as 4 bits to the left of year.
What we don't see here are the bits for the code field. So just how big is the struct?
If we add this to the code:
printf("size = %zu\n", sizeof(struct Message));
We get:
size = 16
It's considerable bigger than we thought. So let's make the bytes array unsigned char [16] and output it. The code:
int i;
printf("m: ");
for (i=0; i<16; i++) {
printf(" %02x", m.bytes[i]);
}
printf("\n");
printf("m2:");
for (i=0; i<16; i++) {
printf(" %02x", m2.bytes[i]);
}
printf("\n");
Output:
m: 09 00 7c 3d e1 77 00 00 00 00 00 00 00 00 00 00
m2: 09 00 7c 01 e1 07 00 00 30 04 40 00 00 00 00 00
Now we see the 0x0400430 bit pattern corresponding to the code field in the representation for m2. There are an additional 20 bits of padding before this field. Also note that the bytes are in the reverse order of the value which tells us we're on a little-endian machine. Given the way the values are laid out, it's also likely that the bits within each byte are also little-endian.
So why the padding? It's most likely related to alignment. The first 5 fields are 8 bits or less, meaning they each fit into a byte. There is no alignment requirement for single bytes, so they are packed. The next field is 12 bits, meaning it needs to fit into a 16 bit (2 byte) field. So 6 bits of padding are added so this field starts on a 2 byte offset. The next field is 26 bits, which needs a 32 bit field. This would mean it needs to start on a 4 byte offset and use 4 bytes, however since this field is declared unsigned long long, which in this case is 8 bytes, the field uses up 8 bytes. Had you declared this field unsigned int it would probably still start on the same offset but only use up 4 more bytes instead of 8.
Now what about the first case where the blob value is 131810088189961? Let's look at its representation compared to the "expected" one:
131809282883593 0x77E13D7C0009 0111 0111 1110 0001
0011 1101 0111 1100 0000 0000 0000 1001
131810088189961 0x77E16D7C0009 0111 0111 1110 0001
0110 1101 0111 1100 0000 0000 0000 1001
These two representations have the same values in the bits that store the data. The difference between them is in the 6 padding bits between the month and year fields. As to why this representation is different, the compiler probably made some optimizations when it realized certain bits weren't or couldn't be read or written. By adding a char array to the union, it because possible that those bits could be read or written so that optimization could no longer be made.
With gcc, you could try using __attribute((packed)) on the struct. Doing that gives the following output (after adjusting the bytes array to 8 along with the loop limits when printing):
size = 8
9:0:0 30.5.2127 code:479
m2.datablob: should: 131809282883593 is: 1153216309106573321
m.datablob: should: 131809282883593 is: 131809282883593
9:0:0 30.5.2017 code:4195376
m: 09 00 7c 3d e1 77 00 00
m2: 09 00 7c 85 1f 0c 01 10
And the bit representation:
1153216309106573321 0x10010C1F857C0009 0001 0000 0000 0001 0000 1100 0001 1111
1000 0101 0111 1100 0000 0000 0000 1001
131810088189961 0x77E16D7C0009 0000 0000 0000 0000 0111 0111 1110 0001
0110 1101 0111 1100 0000 0000 0000 1001
But even with this, you could run into issues.
So to summarize, with bitfields there's no guarantee of the layout. You're better off using bit shifting and masking to get the values in and out of the bitfields rather than attempting to overlay it.
The problem here lies in line 37 where you do:
m2.elems.code = 4195376;
You assigned a invalid type to your bit field:
struct Message {
unsigned int hour : 5;
unsigned int minutes : 6;
unsigned int seconds : 6;
unsigned int day : 5;
unsigned int month : 4;
unsigned int year : 12;
unsigned long long int code : 26; <-- invalid
};
see: https://www.tutorialspoint.com/cprogramming/c_bit_fields.htm
in the Topic: Bit Field Declaration
There it says you can only use int, signed int and unsigned int as Type.
I think the Compiler interpretes m2.elems.code as int and i don't know what he exactly does with an assignment greater than max int.
To reiterate, the layout of bits within bit-field structs is not guaranteed (i.e. it is compiler dependent) and so this kind of bit manipulation is not good practice. To achieve such functionality bit manipulation should be used instead.
A quick example of this might be:
#define HOUR_BIT_START 59 // The bit number where hour bits starts
#define HOUR_BIT_MASK 0x1F // Mask of 5 bits for the hour bits
unsigned int getHour(long long int blob)
{
return (unsigned int)((blob >> HOUR_BIT_START) & HOUR_BIT_MASK);
}
int main (int argc, char *argv[])
{
unsigned long long int datablob = 131809282883593;
printf("%d:%d:%d %d.%d.%d code:%lu\n", getHour(datablob), getMinutes(datablob), getSeconds(datablob), getDay(datablob), getMonth(datablob), getyear(datablob), getCode(datablob));
}
I'll leave the implementation of the other get*() functions to you
I'm trying to print a char array of 4 elements as a float number. The compiler(gcc) won't allow me to write z.s={'3','4','j','k'}; in the main() function, why?
#include <stdio.h>
union n{
char s[4];
float x;
};
typedef union n N;
int main(void)
{
N z;
z.s[0]='3';
z.s[1]='4';
z.s[2]='j';
z.s[3]='k';
printf("f=%f\n",z.x);
return 0;
}
The output of the program above is: f=283135145630880207619489792.000000 , a number that is much larger than a float variable can store; the output should be, in scientific notation, 4.1977085E-8.
So what's wrong?
z.s={'3','4','j','k'}; would assign one array to another. C doesn't permit that, though you could declare the second and memcpy to the first.
The largest finite value that a single-precision IEEE float can store is 3.4028234 × 10^38, so 283135145630880207619489792.000000, which is approximately 2.8313514 × 10^26 is most definitely in range.
Assuming your chars are otherwise correct, the knee-jerk guess would be that you've got your endianness wrong.
EDIT:
34jk if taken from left to right, as on a big-endian machine is:
0x33 0x34 0x6a 0x6b
= 0011 0011, 0011 0100, 0110 1010, 0110 1011
So:
sign = 0
exponent = 011 0011 0 = 102 (dec), or -25 allowing for offset encoding
mantissa = [1] 011 0100 0110 1010 0110 1011 = 11823723 / (2^23)
So the value would be about 4.2 × 10^-8, which is what you want.
In little endian:
0x6b 0x6a 0x34 0x33
= 0110 1011, 0110 1010, 0011 0100, 0011 0011
sign = 0
exponent = 110 1011 0 = 214 (dec) => 87
mantissa = [1]110 1010 0011 0100 0011 0011 = 15348787 / (2^23)
So the value would be about 2.8 * 10^26, which is what your program is outputting. It's a safe conclusion you're on a little endian machine.
Summary then: byte order is different between machines. You want to use your bytes the other way around — try kj43.
What you actually see is {'k' 'j' '4' '3'}